maria-developers team mailing list archive
Mailing list archive
Re: request for advice on managing a mysql patch in bzr
On Fri, Feb 26, 2010 at 6:36 AM, Sergei Golubchik <serg@xxxxxxxxxxxx> wrote:
> Hi, MARK!
> On Feb 25, MARK CALLAGHAN wrote:
>> I know this question is more about official MySQL than MariaDB, but it
>> is also about sharing code we write at Facebook and all of the patches
>> we publish can be reused by others as long as others accept BSD
>> I am getting ready to publish facebook patches for mysql 5.1. We use
>> git internally and are based on MySQL 5.1.44. We intend to stay
>> current with 5.1 releases. What is the best way to manage the code in
>> launchpad across new releases of official MySQL. My current plan is:
>> 1) import MySQL 5.1.44, commit 2) apply patches from my git repo to my
>> bzr repo, commit after each one 3) publish
>> But there will soon be a release of 5.1.45 or 5.1.46 and I don't want
>> to repeat the steps above each time that happens. Do I just publish a
>> large patch for 5.1.44 -> 5.1.4X and get on with my work? Is there a
>> better way?
> The least labor-intensive path, I think, could be something like
> Branch mysql-5.1 tree (say, up to tag:mysql-5.1.44), apply your patches
> and commit. One commit per logical patch, as usual.
> Then when 5.1.45 comes out you rebase (not merge) your tree to
> tag:mysql-5.1.45. Some merges you'll need to resolve manually, others
> bzr can handle automatically.
> When done, you'll still have your patches on top of the tree, and you
> can trivially extract them (e.g. with bzr log -p) and publish them.
> If you merge instead of rebasing, you'll have old patches in the tree
> and merge changes spread over many merge changesets.
That is the advice I need. Thanks.