Supporting cherry-picking

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 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.

If you're talking about ensuring the correct ancestors are in weave
storage, worry not.  They're there, pulled in by a fetch() when you do
the merge.  Fetch always pulls in all ancestors of the requested revision.

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

No, it wouldn't.  Because it would cause lines to be compared against
ancestors that were never merged.  Those lines could then be attributed
to an unmerged ancestor, instead of being attributed to the revision
being committed.

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

No, that wouldn't work because you might get matches against revision
99, which could cause lines to be incorrectly attributed to 99, and
incorrectly marked as deleted (since they were never present)  That
would screw up a later merge of 99.

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

I'm fairly certain it would break badly.

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

I think so.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDXnUh0F+nu1YWqI0RAkBmAJ46cp0eTIWmneH0klERsm1C+KwJ+QCfdtHx
+ZlRSw5fTo8a564IWkrPwdY=
=d6vt
-----END PGP SIGNATURE-----