Thursday, October 25

working with Mercurial

Working with mercurial is a strange/new experience in version management. They called it "the new step" over traditional methods, and I was skeptic.

Now, I'm inclined to agree.

The main difference between Mercurial (and, as far as I understand GIT is the same) and traditional version control systems (CVS, Perforce, VSS et all) is Mercurial's distributed nature: here, every local copy of a repository that you make, is a new repository in itself, supporting retrieving previous versions of the code, adding new changes and merging with other repositories (among other things).

This is confusing, the first couple of times you work with it, but as you go along, you start to see the benefits:
  • you no longer have to wait when getting a previous version of the code (it's a local operation)
  • you can (at any time) re-sync your changes with the master version (having a master version - or more - is completely optional; infact, I undestand that, for the linux kernel development model, there is no master version at all, just some preferred/priviledged repositories)
  • you need not make periodical backups (if - say - you loose your HDD, you can simply clone another repository - unless all the HDDs of all the team members fail at the same time :-))
  • it's under your complete control, and creating and merging repositories is as easy as typing two commands (at the moment I have three repositories on my machine, for working on different things: One for a local "master" copy, one for working, and one for testing Mercurial commands, trying various things and generally playing)


Infact, I like it enough to have switched on my home computer from cvs, to mercurial.

In short, it rocks :)

No comments: