On Sat, Dec 08, 2007 at 03:03:28PM -0500, MenTaLguY wrote:
On Fri, 2007-12-07 at 17:46 -0800, Bryce Harrington wrote:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Have you had a chance to play with bazaar much?
No, I hadn't. Until recently, the general consensus on the web about bzr had been "don't bother". It was generally so ill-considered that I didn't even bother evaluating it when I did the giant SCM bake-off a while back.
However, reviewing the consensus on the web today, it seems that it has improved enough in recent months that people are now rating it just behind git and mercurial. So I will give it a spin.
There is a git-vs-bzr page from the bzr developers here, which might be of interest at highlighting some of the major differences:
http://bazaar-vcs.org/BzrVsGit
The things that to me sound particularly interesting for Inkscape are:
* Cleaner UI model: * Commands set more familiar for Subversion and CVS users * Lower learning curve - only a dozen core commands, users only need about five
* Bug tracker integration (Bugzilla, Trac, Launchpad): * Commits can auto-flip bug states to closed, etc. (Basically, just put "Closes: LP# 12345" in commit message) * Linking branches to bugs and blueprints
* Rich public API: Architecture allows for plugins / custom tools * Many existing plugins: Eclipse integration, web interfaces, log formatting, GUI frontends, etc. - http://bazaar-vcs.org/BzrPlugins * Python API: http://bazaar-vcs.org/WritingPlugins
* Enables larger variety of workflows: Solo, partner, lock-step, centralized, decentralized/shared, decentralized/gatekeeper, and decentralized/auto-gatekeeper
* Run tests on commit: PQM is an auto-gatekeeper that requires commits to pass test suite before being accepted to mainline tree.
* Better asynchronous sharing of patches: The send command generates a "merge directive" which includes metadata with the patch, which can be merged/pulled, or even applied manually via GNU patch.
* Better windows support: Has GUI client, works on FAT32 as well as POSIX, and has well-supported Windows installers.
* Easier administration: * Does repository packing automatically * Upgrade tools for switching between file formats * Branch reconfiguration tools for different workflows
Ted is really fascinated by the PQM stuff. The idea here is that we'd be able to hook up our 'make check' (and/or make distcheck) tests to bzr, so that every time a commit is pushed, a machine would run make check against it, and only if make check passes would the commit be allowed to enter mainline.
Given the number of times a Windows developer has committed an Inkscape change that broke Linux, or vice versa (or OSX), this seems like an exceedingly practical feature. I don't know if git has something like this, but regardless I think it's a feature that'd save a lot of angst in our project.
I'm uncertain about the current state of git's windows client, but I gather bzr's is pretty good. Since the windows client is the major reason we've not considered moving from svn to git so far, this could be a big point. In fact, the reason I got thinking about bzr for Inkscape to begin with was the windows client.
The workflow flexibility (and changeability) in bzr actually maps very well to our Inkscape project workflow. git is designed specifically to the kernel development 'decentralized+gatekeeper' workflow. We in Inkscape follow the 'centralized' workflow where generally everyone checks everything in centrally, except around releases where we switch to more of a gatekeeper type system, except that we have no way of enforcing that.
There's a really nice article summarizing different workflows. It even uses some of our OpenClipart SVG icons for illustrations (if you squint maybe you can see Andy's name on the Computer icon):
http://bazaar-vcs.org/Workflows
If we switched to git, we'd have to change our workflow to follow (not necessarily a bad thing, but forces everyone to change a little.) With bzr, we could retain our current centralized workflow, plus be able to better map to a true gatekeeper system at release time; people would also be able to switch to the decentralized approach as they feel ready by using the "bzr commit --local" option.
The launchpad integration with the auto-flipping of bug states is also a spiffy feature. It's kind of cool to commit code and see the bug automatically close. But I have to admit it doesn't save me much time in practice, since I always write a response to the bug reporter anyway, so manually closing the bug isn't a big deal. It's still fun to have though.
Bryce