miércoles, 9 de septiembre de 2009

mercurial vs git which one to choose?

Lately I've been more and more concerned about the importance of version control systems due to my late work on multiple features at the same time on one of my Evolutionary Algorithm app at $work.

I've been reading some texts about distributed vs centralized version control and the advantages of DVCS seem clear, but not being used to work with other people, nor maintaining various developement branches, I find a bit daunting managing my codes without some reading about DVCS.

Let's do some reading then!

I've briefly skimmed some blogposts and homemade comparisons, and finally I tried to find complete free books.

That's the order I think it's the best to understand pros and cons of one and the other system.
In this first article ( http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ ) they explain the main differences between the two.

Fairly the well-known stuff:
git is more flexible,
git is more cumbersome at first.
git is faster than mercurial.
git installs about 150 binaries in your /usr/local/bin
git makes branching cheap

hg is very robust
hg is well documented (better than git)
hg is ready to use
hg is more compact than git

It seems that hg uses the motto "convention over configuration", and git is just the other way.

Here there are a couple of webs that compare one to other in a more procedural way. How git people tend to work and how hg do it.


And here there are some comparison between workflows in both, git and mercurial. Theese are the key to understand branchy development.


different workflows explained:


Git evangelists && book
http://whygitisbetterthanx.com/ is clearly progit, so it may not be updated respect hg

Mercurial evangelists && book

Yesterday I just finished the 'mercurial definitive guide' book, and theese days I'll take a look at 'pro git', but I think that today, mercurial has the same facilities as git when it comes to branching, and despite not having the staging area, and some other little idiosyncrasies, one can use mercurial with the same workflow as git (one branch for qw/feature bug release experiment/ ). Being able to close branches allows us to use branching instead of cloning , and then end with a update, merge, commit and --close-branch . There's a lot of outdated info about mercurial branching system... you know, teh intertubez is full of moving targets.

All in all, I think I'll keep using hg at $work, and try git here and there on my little github projects.

Next book to finish reading: Effective Perl Programming.
Book I allow myself to start again (and probably won't end): SICP

1 comentario:

Anónimo dijo...

Do you know http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/ already? It really covers the current status of branches in mercurial. But expect bookmarks to be pushable in Mercurial 1.5