Promoting the use of Mercurial; was: Re: gnome dvcs survey results

[Theodore Tso]

On Wed, Jan 07, 2009 at 07:50:36AM -0700, Bill Barry wrote:
> > This somehow bothers me, since it shows that some people use
> > momentum as main argument for switching to git.
> 
> I think that momentum _is_ the main argument for switching to git from a 
> centralized VCS. You will find a git bias in the userbase for git (just 
> like you would find an hg bias in hg users and a bzr bias in bzr users).

People *will* use momentum as an argument, because it makes sense.
The arguments there is two fold; if a large percentage of the
developers already know a particular SCM tool, then there is less
training that will be necessary.  The second argument is that if there
are more people using it, there is likely to be more development for
support tools that surround a particular SCM, and to a lesser extent,
it might make a difference to the speed at which a particular SCM
develops.  Hg can make a counterargument with the latter, based on the
fact that python is a easier language to write extensions than C.
(OTOH, I personally find it easier to write extensions using shell and
the low-level git functions but that's because I never got around to
learning python, but am much more of a shell/sed/awk/perl kind of guy.
Everybody's mileage will vary here...)

Note, BTW, that the other momentum argument is simply number of
developers and relative activity on the mailing list.  The git mailing
list averages about 2900 messages/month; mercurial seems to be
averaging about 470 messages/month.  If there are more people working
on making a project better, all other things being equal, it's a good
thing --- although obviously a few star programmers can make a huge
difference either way.

> The main advantage of git is that there are a lot of people who are 
> familiar with it as you get closer to projects that potentially share 
> developers with the kernel. Outside of this group, git support tends to 
> fall away because of many disadvantages:
> * non-uniformity in command arguments
> * too many core commands
> * relative lack of windows support
> 
> (though someday git will probably solve both the first and last problem)

Arguably most of these problems have been solved already.  Git 1.6 has
already moved out many of the lower-level commands, and if you compare
the outputs of "git help" with "hg help", they are roughly the same.
And the native windows port of git is rapidly approaching usability.

> I think overall that git suffers from a lack of direction.

I suspect you're saying this because you haven't been following git
development.  I track both, and they do have a development agenda that
includes making the UI easier to use, hiding the low-level commands
(already done in git 1.6), and there are developers that are working
quite steadily on the Windows ports.

I'd ask the flip question, which is what is Mercurial's long-term
direction?  Or, put another way, what does Mercurial what to be when
it grows up?  If it's just "faster than bzr, slower than git, but
easier to use and hey, we have a good Windows port", that's not very
satisfying.  So if Mercurial isn't feature-complete, what features are
people planning on adding in the future?

Some other suggestions I'd give for how to promote Mercurial and make
it more competitive:

1)  Work on improving Hg's web site/wiki.  Git got a big boost from the
VC-funded Github company.  If you look at http://www.git-scm.org (the
official git front page) and http://whygitisbetterthanx.com, a lot of
that can be attributed to having some funded technical writers and
evangelists working on the documentation, tutorials, and general
presentation to new users.  Granted Hg is funded primarily by
volunteers, but if you compare the two web sites, while at one point
Hg had the much more approachable and user-friendly web site compared
to git, this is one area where Hg could play some catch-up.

2) Document how to use Hg, especially its extensions, for different
workflows.  For example, one of the things for which Hg suffers from a
public perception point of view is that it can't do certain things,
such as multiple light weight named branches inside a single
repository which can be easily garbage collected.  That's actually not
true; you can do it, but it's not very well documented.  For example,
a key part of being able to do this is to know about the "strip"
command which is part of the MercurialQueues extension.

3) More generally, there is a lot of functionality which are in
Mercurial extensions that aren't well documented.  Unless you know
that the extension exists, or go looking in the CategoryExtensions
page in the wiki, it's easy to miss them and not know about various
bits of functionality.  After all, they tend not to be mentioned in
the hg man pae, or in other parts of the Hg Wiki, since they are after
all, extensions and therefore treated as second-class citizens.

Given that some very nice functionality, some of which is needed to
put Hg on par with other competing SCM's, or in some cases, as in the
Bugzilla extension, cause Hg to to have functionality not available
elsewhere, it would help promote Hg if these extensions were "plugged"
more aggressively.  Maybe a wiki page that lists the most useful
extensions, and encourages people to include them in their .hgrc,
which is linked off of the front page of the Hg website in a fairly
prominent location, for example. Or maybe some extensions should
simply be enabled by default and documented in the Hg man page.

Anyway, just some thoughts/suggestions.  Hope some folks found it
useful.

						- Ted