On Mon, Dec 10, 2007 at 07:39:44AM -0800, MenTaLguY wrote:
On Sun, 9 Dec 2007 16:30:11 -0800, Kees Cook <kees@...62...> wrote:
I'm hoping that subversion stays because then I can use bzr without changing anyone else's workflows. (Launchpad can track CVS and Subversion trees and exports as a bzr branch.)
I do essentially the same with git.inkscape.org. It should still be possible to arrange something like that with e.g. tailor, even if you aren't able to use Launchpad's integration any more.
Agreed. The real benefit with the bzr-from-CVS (which obviously doesn't apply to us) is that the LP tool actually builds logical commits out of CVS, which greatly simplifies dealing with big CVS commits. Anyway, doesn't matter for us.
I wish git or bzr would handle "real" cherry-picking though. I have no idea if mercurial does it right.
Could you elaborate?
Sure. One of the benefits of both git and bzr is the intelligent merging, since they're both very branch-aware. From what I've been able to see while doing git cherry-picking is that while it can hunt down the patch and build a merge for a given cherry-pick, there's really no lasting information that a given patch came from some branch or not.
For example, one of the usb video drivers in the Ubuntu Dapper kernel git tree had been updated for some features. The Ubuntu Edgy kernel did not have those changes. There was no way to query "what branches have been applied to this usb video code?" and I had to muck about trying to apply various upstream branches until I found the one that applied cleanly. As it stands (with both git and bzr AFAICT), there isn't really a way to do backporting cherry-picks. You _can_ do cherry-picks, but it's really nothing more than an elaborate "find a patch" process (which, don't get me wrong, is nice but it kind of feels incomplete).
Again, I'm bringing up topics that don't really apply to making a decision about a VCS. :P