There and back again

[Andrew Cowie]

I have a branch with the next major new feature being developed in it. I
was hoping we would get this branch finished & merged before the next
release, but that's not going to be possible.

Despite my best efforts, there are a number of things on that branch
that really ought to have been independent and on orthogonal branches,
but hey, it happens.

So I'm going to get as much of the relevant stuff off of this long-lived
branch and into 'mainline' as possible.

There are two ways I could do this:

1. Use merge to cherrypick

Assuming I can identify files and/or revisions, I use `bzr merge -r
X..Y` a whole bunch of times, and away we go.

This is the classical approach, and works fine. The only drawback is
having to identify the bits in the first place, and having to create new
commit messages. [It also screws up annotation, but that's a problem
with gannotate & lines that have more than one revision creating them
that hopefully someone will find a way to fix in the future]


2. Merge the whole branch and then during the merge revert all the stuff
that isn't actually 'mainline' ready.

This is tempting, because it will be a lot easier to just bam! revert
the files that are the real heart of the long lived branch, letting the
remainder be one nice merge.

At first I thought that this would be good because revisions which
created the changes that are being merged will be correctly identified
(unlike with a cherrypick above). But then I looked into what would
happen when 'mainline' gets merged back into the long-lived branch.

I go to do the merge, and of course it wants to delete or otherwise
remove everthing which special about the long-lived branch I'm merging
back to. So, fine, one quick revert and everything is back to normal.

But annotation is screwed up again. Now it thinks that this merge was
the origin of all this code, and so the revisions that created them (and
their lovely commit messages) are all blotted out. And, of course, there
are all these revisions merged to 'mainline' whose code isn't actually
present anymore. That seems strange to do on purpose.



So it seems lose, lose either way. I realize that gannotate not knowing
what to do with the mutliple-revisions : one line thing is clouding the
picture, but my question to you is whether or not there is a Bazaar
internals reason to pick one way over the other? I'm pretty sure both
are "safe"; (2) is probably less work, but revert, revert again punch
counter punch worried me a bit.

Any suggestions (including, "it's fine, stop worrying about things so
much") would be appreciated.

AfC
Sydney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080724/90c54317/attachment.pgp