Darryl Mocek

I've recently had a chance to take Mercurial for a test drive. For those of you who haven't tried it yet, get ready for a mind-shift. The biggest difference between Mercurial and other Source Code Control Systems (SCCS's) is that most other SCCS's enforce a master-child relationship between the master repository and "child" repositories. You typically create a master repository which is used by everyone as the place into which changes will be put. This is a good thing. Everyone must commit to the master repository and everyone must make sure their commit is correct and doesn't break the build. Everyone gets the latest updates from the master repository. It's a central "meeting" place for code. One problem with this is you don't have a full, complete copy of the repository from which to work. This may cause a problem when you're taking your code mobile.

Mercurial is different in that it is a distributed peer-to-peer system. If you create a repository on a server in your group, there is nothing special about that repository from Mercurial's perspective. You pull the code from the repository on that server and now you have a copy of the code on your local machine which is equivalent to the one on the server...commit comments and all. Need to take the code on the road? Pull the code from either your local copy or the server's copy to your laptop...both are the same. Need to commit changes? Commit from your laptop to your local copy or the server's. If you commit from your laptop to the server, you'll need to pull the committed changes from either your laptop or the server to your local copy...again, both are the same.

In Mercurial, the "master" repository on the server is a convention only. You and your group decide you want to have a "master" repository on the server and so you treat it as such. Mercurial doesn't care. I think this model works better in our increasingly distributed, increasingly mobile work force.