There and back again

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry it took so long to respond. I'm not sure if we have a great answer
for you or not, but I'll see what I can come up with.

Andrew Cowie wrote:
| 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]
|

It sort of depends what *you* consider a "fix".

|
| 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
|

I think the biggest thing would be to get proper cherry pick support
functioning.

http://bazaar-vcs.org/Specs/RecordCherryPick

Then style (1) could give you proper annotations, without giving you the
double-revert issue.

I'm a little surprised that annotate isn't giving you better results. I
thought it did a diff versus the left parent and assigned results to it,
and then only for the remaining changes would it assign it to the merge.
Certainly there are ways to do that.

Now, if you did:

bzr merge mainline
bzr commit
bzr revert -r -2 some/files
bzr commit

Then I would certainly expect to see what you are saying. But if you did
it as:

bzr merge mainline
bzr revert some/files
bzr commit -m "merge mainline, but preserve my changes"

I would have thought annotate would handle that correctly. (At least
with my 'simple_annotate' patch (just posted) or my annotation_policy
patch (posted a while ago.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiPTgIACgkQJdeBCYSNAAOd6gCggPNzuvc2Eil7O/DpQNQ0c8AA
P34An1U/m+WaYMHt1RljtjnY3p+9fPHt
=MA1a
-----END PGP SIGNATURE-----