Re: Mercurial vs Updated git HOWTO for kernel hackers

[Kevin Smith <yarcs@qualitycode.com>]

Andrea Arcangeli wrote:
 > On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
 >
 >>Cool. Except where the concepts are just different, Cogito mostly
 >>appears at least equally simple to use as Mercurial. Yes, some
 >>features are missing yet. I hope to fix that soon. :-)
 >
 >
 > The user interface and network protocol isn't the big deal, the
 > big deal is the more efficient on-disk storage format IMHO.

For me, efficient storage is not very important, because I mostly deal 
with small projects. Likewise, speed isn't a factor for me, since both 
tools are plenty fast on small repos.

For me, the big advantage of mercurial is that it is written in python, 
instead of shell scripts. I know for some people that's a DISadvantage, 
but I see the following benefits as a result:

- Can run on (native) MS Windows
   (necessary for me because I often work on cross-platform projects)
- Python code can be more clear and expressive (IMHO)

In the long run, I think the python code base will be easier to maintain 
and enhance. A rewrite of cogito in python or ruby would be cool.

One advantage that cogito has is that git viewing/browsing tools can 
operate directly on cogito repos. But a psychological drawback is the 
ongoing confusion between git and cogito. Questions: Would a git-based 
tool that writes to the repo (such as StGIT) mess up a cogito repo? Can 
you switch a repo between git and cogito or back, at any time?

Mercurial's tags use a radical approach, whereas cogito's are more 
conventional. I haven't yet used mercurial's versioned-tags enough yet 
to judge whether they are better, worse, or just different.

I am impressed with the vibrancy of the development communities of both 
projects. Both are able to serve repos on a plain http server. Both are 
easy to use and have decent basic feature sets. Both projects are 
developing test suites.

Mostly, I'm thrilled with this new wave of lightweight distributed SCM 
systems. Most of the established tools tended to be too heavy on 
features and complexity, and have taken a long time to develop. I love 
that a single developer or small team can now create a simple but usable 
distributed SCM in a couple months.

Kevin