DVCS comparison for our organisation: decided

[Ben Finney]

Ian Clatworthy <ian.clatworthy at internode.on.net> writes:

> Ben Finney wrote:
> > Our organisation has chosen Mercurial, based largely on
> > more-mature and better-documented support for repository
> > commit-time actions.
> 
> We did add some improvements to the hooks doc in 0.91 but they
> weren't rolled out well enough in two ways:
> 
> * it looks like 'latest' is still pointing to the 0.90 docs
> * the hooks.txt ReST source never got converted to html on the web site.
> 
> I assume you found the information in the User Guide OK

I was only able to find this past the deadline, which was enough of a
black mark against Bazaar's documentation that it wasn't considered.

> It's a fair comment that we could do a better job with packaging
> hooks that we do. Right now, hooks can be arbitrary python code so
> they can do pretty much anything you want. That's flexible but not
> to everyone's liking.

In particular, Mercurial's support for arbitrary shell commands is
superior for our needs.

> 1. Do we provide hooks in the places you need? (We have plans for
>    better hooks support on the smart server but that will only
>    help for orgs that *only* use that technology and not other
>    technologies.)

The ease of specifying *commands*, which don't require knowledge of
any programming language except command shell, is what helped
Mercurial in this area. The majority of our target users don't use
Python and asking them to write valid Python just to tell the VCS to
run shell commands would be perverse.

> 2. Are there pre-packaged scripts we ought to provide for common
>    hook tasks rather than leaving it up to users to provide the code?
>    That sounds easy to do, either directly in the code base or on
>    a wiki page.

The ones that come to mind are:

  * run an arbitrary shell command pre-commit, and reject the commit
    if that command has a non-zero exit code

    This would be to allow 'make test' or whatever shell command is
    needed to run a test suite.

  * run an arbitrary shell command post-commit, and send an email to a
    per-repository customisable address if it has a non-zero exit code

    This would allow notifications of commits to the repository.

  * send an email, post-commit, to a per-repository customisable
    address, with a per-repository customisable message template
    (defaulting to a simple template)

    This would allow automated build systems or the like to kick off
    on any commit to the repository.

There are likely others, but we'll discover those as we go.

> For those that want the discipline it implies, PQM is a cool
> *addition* to Bazaar.

I don't doubt it, but its lack of Debian packaging (in Debian
'testing' branch) is a significant barrier for us. Any such "cool
additional tool" needs to be very easy for us to administrate, and
managing installed-from-source tools is additional administrative load
we don't need.

> We need to get the core Bazaar product right regardless. Any
> additional feedback you can provide us to make sure Bazaar Just
> Works would be much appreciated.

I believe there is work currently underway to improve Bazaar's startup
time? We didn't measure it, but the perceived difference in startup
time between Mercurial and Bazaar was quite marked (in Mercurial's
favour) for a simple cold (i.e. nothing cached) startup of the tool.

Part of "the core Bazaar product" is the information points people use
to get to it; if they can't find out about it well enough to decide
it's worth using, it doesn't matter how good the tool is for them,
they're prevented from getting there by the lack of information to
make that decision.

The Bazaar website is frustrating to navigate for information. Dates
are particularly lacking; information will refer to "working on this
now" and not be dated at all, or refer to "May 12" with no year. This
makes it very difficult to know what is current, and lowers the
reader's confidence in *any* of the information.

Instituting a website policy of "always apply a fully-qualified date
to any temporal information, even casual comments" would help in this
regard, and would also assist future people to summarise or remove
outdated stuff.

I hope this is of some help.