DVCS comparison for our organisation: decided

Ian Clatworthy ian.clatworthy at internode.on.net
Tue Oct 16 08:27:37 BST 2007


Ben Finney wrote:

>> 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.

Ok. We clearly have some work leave to do to make finding things in our
doc clearer then. Can I ask which version you evaluated? If 0.91, did
you look at the doc installed along with the package or just the web site?

> 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.

Thanks for the feedback. FWIW, here's the python script to run a shell
command:

import os
os.system('echo "Hello World"')

where 'echo ...' is anything you want. I'll have a look at making that
even easier so users can specify a shell command line directly in a
file. It's really very simple though - 2 lines - for cases when a shell
command line is good enough.

The only other comment I would make in this area is to be cautious about
the 'appearance' of simplicity during an evaluation. The huge advantage
to using Python over shell command lines is context - you get access to
interesting data inside the hook code. The increased complexity required
to call out to a shell from inside Python - the two lines above - is
quickly paid for compared to the pain of parsing/navigating context data
inside a shell script. Simple is good: too simple can turn into a
nightmare the moment you want to do anything beyond 'make test'.

>> 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.

These are great. Thanks.

>> 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.

Understood. My point was that PQM is not Bazaar and your need for it or
otherwise is actually an independent issue. PQM is useful regardless of
which VCS you choose so rejecting Bazaar because PQM lacked doc suggests
to me than you might have missed the point of it. Again, that points to
clearer doc on our part I guess.

> 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.

We are *very* focussed on performance right now - that's part of the
reason for my delayed response. If by cold startup, you mean

  bzr version

after first installing it compared to running that command a 2nd time,
that's always going to go against us because of the interpreted nature
of Python - we load more libraries than Hg. It's a pretty meaningless
measure though IMHO. If you mean 'bzr init; bzr add; bzr commit', then
that's more interesting. We're tuning that right now with great results.
Once again, it's still a one off exercise for most teams though.

> 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.

Yes thank-you. We'll take the feedback on board and make some changes in
coming months to improve things.

Ian C.



More information about the bazaar mailing list