Cherry Picking

CherryPicking in the context of revision control is to merge only very specific changes from one branch to another.

For example, If you have several branches, and one of the uber-unstable and utterly wacky development trees gets a very important fix, a VCS with good CherryPicking support will let you move only that change to your stable branch quite easily. A VCS without such support will probably mean you'll have to do it manually, thus losing the VersionControl semantics of that patch's history, as well as creating future conflicts if the development tree is wholly merged into the stable one at some later point in time.

DavidsAdvancedRevisionControlSystem is a VCS with excellent CherryPicking support.

Any RCS based on patchsets rather than files or directories will be able to do this. BitKeeper and GitVersionControl are good examples.


MattMackall?, creator of the MercurialVersionControl system, provides arguments against CherryPicking as implemented in DavidsAdvancedRevisionControlSystem [retrieved from http://www.w3.org/2007/03/22-hg-talk-minutes]:
Matt: cherry-picking is ...
... given 2 branches where you want to bring in single changes without regard to surrounding history, Darcs lets you do this
... what I understand from bzr folk is that the way Darcs handles patches internally it's possible to reorder patches such that older versions of the project cannot be reconstructed
... if what I've heard is correct and we're understanding this correctly, this is a serious failing in a version control system
... so (c) Darcs may have some theoretical and practical serious issues

He also provides solutions for how he advises to perform the CherryPicking in Mercurial, and this should be also applicable to other VersionControl systems which are "history-oriented" [http://article.gmane.org/gmane.comp.version-control.mercurial.general/5037]:

There are a bunch of subtly but critically different things that get called cherry-picking. One is "import just a few changesets from a source one time", another is "regularly pick some subset of changes from a source and remember which things we didn't want".

The first can be solved to varying degrees with export+import [of patches], transplant [plugin], etc. This changes ids because you have a different history.

The second, much trickier one is maybe best solved by merge+backout. You can think of it as "cherry-winnowing" (pick all the cherries, then throw some rotten ones out).

MateuszCzaplinski

EditText of this page (last edited January 28, 2011) or FindPage with title or text search