Re: Mercurial vs Updated git HOWTO for kernel hackers

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