Thoughts on Mercurial and Git

[Tim Post]

On Tue, 2007-03-27 at 09:08 -0500, John Goerzen wrote:
> Hi everyone,
> 
> There's been some interesting discussion lately about Git and Mercurial.
> Ted T'so, a Linux kernel hacker and maintainer of ext2/ext3, uses
> Mercurial for e2fsprogs, but comments about thinking of switching it to
> git here:
> 
> http://tytso.livejournal.com/29467.html
> 
> Ted is a very sensible person that I respect quite a bit, and I think
> he's got some valid points.
> 
> He also commented on my post about why I'm still using Mercurial here:
> 
> http://changelog.complete.org/posts/596-Some-more-git,-mercurial,-and-darcs.html
> 
> again with some valid points.
> 
> His main complaints against Mercurial seem to be:
> 
>  * Difficulty of extending it without using Python
> 
>  * Lack of git-style in-tree branches
>    (I have to say I think hg's in-tree branches don't work for my
>    workflow, either)
>  
>  * Repository size and performance
> 
>  * Future features
> 
> I'm not planning to switch to git anytime soon, but I'm wondering what
> people in this community think about all that.  Personally I think that
> the repo size and performance are "nice to haves" (hg is plenty fast for
> me and nearly as small at git).
> 
> But having the history of each file stored in individual history files
> makes hardlinking the history pretty much useless in some cases.  (Apply
> one change that impacts 50% of the files and 50% of your hardlinks have
> to go away, even if you're just updating a copyright date)
> 
> I also gather that someone is working on the branching problem.
> 
> -- John

I think most of his points are valid, but can also be features not
drawbacks depending on your vantage point.

I'm going to be using Mercurial for Gridnix, http://gridnix.com which is
a cluster suite built around Xen for Linux. I went with mercurial
because Python is preferred by most developing our project, we have many
small repositories with many immutable changesets becoming their own
versions, and like the fact that Mercurial isn't going to change a whole
lot.

Our method is build from source, always. Every package that Gridnix
installs will be from source, which is pulled via mercurial from our
repos (when its done, anyway). Python is universal, the client features
aren't likely to change drastically .. its an ideal fit. It makes
packaging our own versions of things really, really easy and keeping web
applications updated even easier.

I would really like to have some kind of working in tree branch, but I
can do without it and work around it without much hassle. 

I guess its a right tool for the right job question. I'm glad many exist
for this reason. But, in all fairness.. for me those are perks not
problems :)

Best,
--Tim