Supporting cherry-picking

[John Arbash Meinel]

Aaron Bentley wrote:
> Hi all,
> 
> One of the prime advantages of weave merging is its support of
> cherrypicking.  But right now, we're not recording cherrypicking in a
> way that takes advantage of this, because weaves don't record
> cherrypicks at the moment.

I would say that we need to actually merge in the revision (along with
all of it's ancestry), so that we have a proper representation in the
weave file. And then the final commit for that file needs to have both
parents properly set.
I think that would make the weave file come out correct.

I don't know that it is a nice way of doing things. But it means that
you always stay consistent.

An example: If you pull in the "NEWS" changes revision from 100 in
Martin's tree, you get all of its ancestry, but you don't apply all of
that ancestry to the local NEWS file. The merge would only apply the
specific changes you asked for. Then for that file, the pending-merge
bit would be set, saying that you merged against 100. Or maybe it would
need to be the pending cherrypick.
Whatever it needs to be, it would mean that the commit could should
compare the current text to the complete text including the merge
ancestor, and the current tree ancestor.
Couldn't it then determine that "all these lines came from mainline
ancestor, but these 2 over here came from the alternate ancestor, and
these superceed both ancestors".

I'm not sure how this really effects if you ever try to do a complete
merge. You would have the correct lines labeled "revision=100", but it
might also state that all the other lines for revision=99 were
superceeded, when they were never attempted.

So is the correct method to have incomplete ancestry for cherrypicked
revisions?

My method would probably also fail the cherry pick 100, then cherry pick
99 test.

John
=:->


> 
> When we do a cherrypick (bzr "merge ../bzr.dev -r -2..-1", where -2 is
> not an ancestor), we do not set any pending-merges.  I believe this to
> be the correct behaviour.  However, when committing the results to the
> weave, this means that the lines will not be correctly attributed to the
> revision they originated from.
> 
> Another kind of cherry-picking is per-file merging, e.g. "bzr merge
> ../bzr.dev NEWS TODO".  (This is not currently supported on the
> commandline, but it would be easy to expose that functionality.)
> 
> Here's an evil case:
> $ bzr merge ../dev -r -2..-1 NEWS TODO
> $ bzr merge --force ../dev -r -5..-4 README
> $ bzr commit
> 
> To be absolutely correct, therefore, we'd need to track which revisions
> were applied on a per-file basis.  This would not be the same as
> pending-merges, in that it would not affect which parents were
> associated with the revision.  However, it *would* affect the parents
> associated with each *file* revision.
> 
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051025/0b7a1b0f/attachment.pgp