maintaining patches on two different bases

Adeodato Simó dato at net.com.org.es
Wed Nov 7 15:47:56 GMT 2007


* Jack Andrews [Wed, 07 Nov 2007 17:31:26 +1100]:

> hi,

Hello Jack.

> i have to produce two sets of patches, one based on mysql 5.0.46 and
> another based on 5.1.22.  i have been controlling my changes by
> putting the source for 5.0.46 into a local bzr.  now i have to produce
> a patch for 5.1.22 as well.  what's the easiest way of doing this?  i
> have to continue development in 5.0 or 5.1 and continue to produce
> patches for both.  will the rebaseing plugin help here?  will rebasing
> my 5.0 tree to 5.1 help?  will i need to keep the original and the
> rebased copy?

I could be wrong, but I don't see rebasing helping here. What I think
could work is:

  1. cretate a bzr branch by importing 5.0, let's call it mysql50
  2. bzr branch mysql50 mysql51
  3. import the sources of 5.1 into branch mysql51, and commit (running
     `bzr add` first; ideally you'd have to check if there were any
     renames; maybe the import command from bzrtools can help with that,
     I'm not sure)

  4. bzr branch mysql50 myfeature
  5. make your changes on the myfeature directory, and always there

  6a. bzr branch mysql50 myfeature50
  6b. bzr branch mysql51 myfeature51

  7a. cd feature50 && bzr merge ../myfeature, resolving conflicts
  7b. cd feature51 && bzr merge ../myfeature

You can now produce patches against both versions by diffing mysqlXX and
featureXX. Repeat 5 and 7 as appropriate.

If new releases of MySQL happen (say, 5.0.47 and 5.1.23), import those
sources onto mysql50 and mysq51, and then:

  % cd feature50 && bzr merge ../mysql50
  % cd feature51 && bzr merge ../mysql51

If at the moment you only have a single branch with 5.0 and your
commits, and you'd like to preserve your history, you can do something
like:

  % bzr branch -r N yourbranch mysql50

where N is the previous commit to the first commit for your feature. The
rest should work the same.

Let me know if you have any doubts with this scheme. Also, I'm sure
somebody in the list will correct me if this is somehow wrong or not
optimal.

HTH,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.
                --  Laurence J. Peter




More information about the bazaar mailing list