I've been thinking about distributed revision control systems again, and I want to start a discussion about cherry picking.
Here's the scenario. Consider two branches of a source tree, let's call them stable and unstable for the purposes of this discussion, but they could be e.g. Andrew Morton's tree and Linus' tree, or whatever. A bug is noticed by the unstable dev, and fixed. Now, or later, we want to "cherry pick" (or "backport") that bug fix, but not all the destabilizing changes on the whole unstable branch. This can be done manually, by creating a patch for the bug fix and applying it. The argument for explicit cherry picking support in a DRCS is that it can (supposedly) figure out ancestor patches that the bugfix depends on and bring them in as well. This is what darcs does. This is of course on a patch level, not a semantic level. Does your favorite DRCS handle cherry picking? How well does it handle it? Have you ever used it? Have you actually found it useful? I have on occasion used darcs' cherry picking support, but mostly for simple changes that had no dependencies in the first place (e.g. config file changes). My hypothesis is that there is no real practical use case where the ability to cherry pick is really important. The convenience of being able to browse/pick the patch(es) you want is important, but that could easily be implemented on top of almost any DRCS (unless it's so braindead as to not let you produce diffs between arbitrary changesets). Once you have the patch(es) you want, they will either apply to your working directory or they won't (the patch layer). Then, they will either work or they will need patching up (the semantic layer). If your DRCS grabs ancestors to make the patch layer work, you may end up grabbing more than you want, and have to manually back things out. If your DRCS doesn't grab ancestors, you may have to bring in more patches yourself, and/or hand-merge, but you won't have to deal with backing out over-eager patches. In either case it works well if you have committed small and specific changesets, and doesn't work so well if you haven't. In both cases you need to be alert and careful, because the software can't do all your thinking for you. That's my latest thought pattern, but I am far from settled in my opinion, and I would like to solicit your discussion to help enlarge my mind. In my case, I'm trying to decide whether to abandon darcs for mercurial (hg) or hold out hope that one day darcs will get over the exponential merge problem. Right now I sit on the fence. I use hg sometimes and darcs other times. I'm quite happy with both tools, and both have their pros and cons. The thing that makes me most uneasy about darcs (aside from the occasional exponential merge problem) is that it's inconvenient to do "point in time" checkouts, branches, etc. The thing that makes me uneasy about hg (or indeed most other DRCS's, to my understanding of them) is the lack of cherry picking. But thinking back on it I haven't ever truly used it in darcs either. Another thing about darcs is that it's hard to really diverge on a branch and still interact with the main trunk. It doesn't (currently) have a way to say "no, thanks, I don't want this patch EVAR so quit asking me every time I pull". In practice this means you have no benefit over any other RCS's branching (where merging is all or nothing). So finding the patch to cherry pick is either a manual affair anyway (though darcs does make it really nice to select patches by description or date or whatever) or quite shallow in which case the whole dependency thing is moot. Phew. :-) What are your thoughts? -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
