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

[Theodore Tso]

On Thu, Jan 08, 2009 at 11:10:46AM +0100, Alpár Jüttner wrote:
> Am I right when I'm saying that this is a good example of a bad and
> obsolete software design?
> 
> I have a feeling that the productivity difference between C and Python
> may easily compensate the larger developer base of git.

That way lies software design religious arguments, which might be
useful if you're trying to convince the python developers which SCM to
use, but might not necessarily sway anyone else.  :-)

Personally, I found it easier to get started hacking git because I
don't speak Python, and git exposes much more of its low level
interfaces via the shell.  Thus, it's much easier to prototype various
extensions in any language of the developer's choice; you can use
shell, C, perl, even python (the tool to allow bidirectional
gatewaying between git and Perforce is written in python).  With Hg,
for bette or for worse, if you need to write an extension that
manipulates the low-level bits of the repository, it has to be done in
Python.

It's also the case that because the low-level bits are might be
extended by non-C programmers, they are documented to a very high
degree via man pages.  Mercurial's low-level documentation is not
nearly as good.  One might argue that it's not necessary since you can
just read the Python sources, I suppose, but (a) that doesn't help you
if you aren't fluent in Python, and (b) if you're going to be using
arguments about how Hg is better from a "clearly superior
architecture" point of view, using the argument, "Read The Source,
Luke" as the excuse for not having good technical developer's
documentation might expose you to a certain amount of mockery.  :-)

On Thu, Jan 08, 2009 at 01:08:34PM +0100, Isaac Jurado wrote:
> And, by the way, I think the Gnome comunity needs much more developer
> pressure in order to migrate from SVN to a DVCS.  They have a couple
> of uncovered workflow related issues in this regard.  Take the LLVM
> people, for example.  They chose SVN instead of a DVCS on purpose,
> because such a centralized model forced all their developers to be
> more up to date.

I'm not sure that argument makes much sense; no SCM forces developers
to be up to date.  Whether you are using CVS, SVN, hg, bzr, git, or
anything else, you can always development against an older point in
history.  Some systems might make it artificially more difficult by
having lousy branch support, I suppose, that's really not much of an
argument.

I agree though that talking about how Hg can support different of
workflows *is* a good idea; and this is one area where bzr and git do
a much better job today compared to Hg.  Indeed, I've made that
sugestion already --- and I'd encourage that it include git's home
turf, which is being able to make lightweight branches inside a
repository to either test out a particular idea, "peek" at what
another developer happens to be working on, or as a temporary
testing/integration branch, which are then thrown away.  (If the
checked out working directory is very large, making a separate copy of
said working directory as the only way to support temporary branches
is highly inefficient.)  Hg can support this, but how to do this is
not well documented, since it involves using tools like hg strip from
the Mq extension.  It's much better to document how to do it than to
say, "that's a bad workflow"; that argument is the best way to send
some projects to go searching for another DSCM that can support that
sort of workflow more easily.

BTW, Mercurial really needs to add better support for renaming and
deleting branches to best support this particular workflow...

	 	     	  	       		  - Ted