Cherrypicking (was Re: ...)

[John Arbash Meinel]

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

Andrew Cowie wrote:
> On Wed, 2007-11-14 at 11:09 +0100, Erik Bågfors wrote:
>> I know that [cherrypicking] is a deal-breaker for some people.
> 
> Speaking personally it's not so much that it's a deal-breaker as it is
> that the lack of it makes my job as project maintainer a real pain in
> the ass.
> 
> Of course, not everyone means the same thing by cherrypick, which
> complicates matters.
> 
> Here we go with the revision is not a changeset thing again, but what
> I'm trying to do is pull the changes caused by a revision(or range
> thereof) from some other branch into this one.
> 
> It comes up a LOT for us - particularly when we have a major development
> branch running and want to pull a number of (orthogonal) features out of
> it so they can be published in the 'mainline' while development
> continues. It also happens a lot when much of a contribution is worthy
> of being accepted to 'mainline' but not all. I'd far rather "cherry
> pick" the good stuff rather than committing something that
> destroys-by-reverting the other work.
> 
> It seems really weird to me that I can't pull "those revisions" and if I
> do the whole `bzr merge --force ../other/filename` thing it doesn't
> import the changelog entries, or the author credit, or any of that
> stuff.
> 

Just a quick comment. All of the systems I've come across that allow very
obvious cherry picking (I have revisions 10, 11, 13, but not 12) do so by using
some sort of set() of revisions, rather than a DAG of revisions.[0]

Which starts to scale *very* badly when you have 100,000 revisions, because you
now need to load the full set to figure out what you have versus what you are
missing. A "merge" in those systems generally has to check every single entry.

We have thought a lot about how we can keep the nice DAG property of "if you
have TIP, stop looking", and still allow for pieces to be chopped. Our current
graph only has edges which say "this is a parent, as are all ancestors".
Another possibility would be to have a way to give a non-recursive edge. We
would still need to figure out what that means for all the other operations.

For example, when you merge from a branch which has been cherry-picked, do you
treat them as regular merges, so you only merge things after the last cherry
pick? Or do you try to cherry-pick "in-between"? If you have done a full merge
after cherry picks, shouldn't it clarify that as of now, everything is
completely merged?

What should happen if I have 1-9, I cherry pick 11-12, and then go back and
cherry-pick 10? Should it set 12 as a full-merge target?

What about cherry picking some changes to a file. When I "bzr annotate" it
shouldn't try including revisions which weren't cherrypicked, right?

Which means that we need to create a text which has never actually existed, and
consider it the parent of the new text. It gets pretty hairy.

If you have ideas on how to implement this. We are certainly interested. Even
if you only have use-cases, please put them on the wiki:
http://bazaar-vcs.org/Specs/RecordCherryPick


John
=:->

[0] This is from investigating Darcs, BitKeeper, and Arch. I don't know of
others that have cherry-picking as a first-class object.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQ1iVJdeBCYSNAAMRAvylAJ49w80JgCE/OXRi5S1Is4NrxRQ/9QCgs5gU
1Vh1h1DGUUaxzIgf1q2npXo=
=znwz
-----END PGP SIGNATURE-----