What do you think about cherry picking?
dave at thesmithfam.org
Thu Nov 29 09:36:18 MST 2007
I haven't used it, but it seems that for me the main problem with quilt
is when files change names (or move to entirely new directories) between
the development and stable branches. This is why VCS integration is
critical, because it knows where the files went and how to "patch" the
patches in order that they get applied to the right files when merging
Ideally I would love a VCS that knows my language, but my main language,
C++, kind of sucks for file management since it allows files to be
wherever you want, and relies on environment variables or compiler
command line arguments to find them, neither of which a semantic VCS
would have access too.
Hans Fugal wrote:
> 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
> patches around).
> 1. http://savannah.nongnu.org/projects/quilt
> (I can never find this at the quilt page, so I host a copy)
> 2. http://hans.fugal.net/quilt.pdf
> 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.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG