What do you think about cherry picking?
hans at fugal.net
Thu Nov 29 07:56:24 MST 2007
Indeed what you mention is a common use case and a very important one.
Ideally, the VCS would allow you to cherry pick that patch to stable and
merge it into unstable (of course you may have to manually intervene in
the merge process... but you may not).
Darcs does allow this, and it works well in this use case. Where darcs
loses its polish is when there are some patches on the other branch that
you *don't* want to pull. It will ask you every time about them and that
gets annoying. But when the only changes going on in the other branch
are bug fixes, you wouldn't run into this.
With other VCSes, cherry picking is less supported. I'm not clear on the
internals, but git has a cherry pick function. Mercurial has an
extension (transplant) for doing it. If I'm not mistaken, in both cases
it's just an automation of the process "make a patch between revision A
and B on the stable branch corresponding to changeset B, and apply it to
the working directory and help out with the merge." That is, it's only
the appearance of supporting cherry picking, not fundamentally supported
by the underlying changeset model.
However, before you start knocking them for this, I'm not entirely
convinced it's not the best approach in the end. Except in trivial cases
this business of pulling in patches from other branches (whatever they
be) *does* need human intervention. Until the VCS knows code semantics
and can guarantee that that patch isn't going to break something (HA),
the human needs to be in the loop. So I say, step back and look at the
problem differently. If the VCS can help you with the tedium of this
manual process, great.
But there's another VCS-agnostic tool that does an *excellent* job of
doing just this sort of thing. It's a little-known easy-to-use utility
that more people should know about and know how to use. Its name is
With quilt, you can maintain a stack of patches against any directory
tree. You can push and pop the patches from the applied stack at your
leisure. It's a great tool for isolating bug fixes or features into
their own patches and for emailing them or copy/paste. So let's look at
your use case.
You have a stable branch, and you make a fix. If you use quilt to track
this fix, then when you've polished the patch to perfection you have a
patch in the patches/ subdirectory ready to go. You apply that patch to
your development branch using your favorite graphical merge tool (or
deal with .rej files by hand if you're masochistic). Then you check in
the changes on your unstable branch. The downside is that now you
haven't got these changes in revision control on your stable branch. No
problem, you can revision control the patches directory.
Mercurial integrates all of this with mercurial queues, which is based
on quilt. It behaves almost identically to quilt, but it makes applied
patches *look* like they are real changesets on the branch. Later, you
can choose to fold them into real changesets (a la pinocchio). It's a
good integration while still giving you the flexibility of quilt.
Quilt is a great tool for contributing to open source software, esp.
where you're not a trusted developer. You download foo-1.0.tar.gz and
unpack it, find that it doesn't build on your machine, and so you use
quilt to help you make a patch. Then quilt helps you to send the patch
in an email. Later you want to add a little feature but you don't want
to confuse that code with the compilation fix in the patch you'll send
off, and the devs are lazy bums and haven't applied your compilation fix
yet. No problem with quilt.
So in short, hg, darcs, and git do have various kinds of support for
your scenario. If this is a tipping point to getting you to try a
distributed RCS, then go for it! But secretly, I think the more general
tool and the one that you really should check out is quilt. Quilt will
be your friend in diverse situations and regardless of which VCS is in
use (including none). It works for some kernel developers. The workflow
works for even more (it originated with Andrew Morton's patch scripts,
and of course the whole linux development model is built around flinging
(I can never find this at the quilt page, so I host a copy)
On Sun, 25 Nov 2007 at 19:43 -0700, Dave Smith wrote:
> Hans Fugal wrote:
> >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.
> Sorry for the late reply, but thank you for the thought provoking post.
> I have often wondered about this, although in a slightly different scenario.
> My scenario is very similar to the one you describe, but backwards. I
> usually do a release, branch the code (in Subversion or CVS), and
> continue on with new development in the trunk, making only bug fixes
> (theoretically) in the branch. After branching, if a customer requests a
> change in the release, we fix it in the aforementioned release branch,
> which of course we usually want to merge into the trunk. For me the
> merge is almost always a manual process, except in the most trivial
> cases (which get more rare as the two code bases diverge over time).
> This seems like an extremely common scenario, and I've always been
> surprised at how hard it is to do. It ought to be trivial given the
> frequency of the task. Does your distributed source control system of
> choice make this easier?
> Sorry I haven't answered your question. I'm still trying to figure out
> things myself.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20071129/df24799d/attachment.bin
More information about the PLUG