Dave, 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 quilt[1]. 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. > > > > Hans, > > 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. > > --Dave > > /* > 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
signature.asc
Description: Digital signature
/* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
