Notes on Java, Solaris, PHP, LDAP…

November 27, 2007

Notes on Mercurial SCM, compared to Subversion and GIT

Filed under: Uncategorized — negev @ 5:55 pm
Tags:

Mercurial – Source Control

Mercurial (hg) is a distributed versioning system. I’ve installed it and tried just a little. Following are my notes based on http://hgbook.red-bean.com/hgbook.pdf and my experience.

Mercurial and GIT are both free distributed versioning systems. Main differences – GIT possibly a little faster, but it requires maintenance (repacking the repositories). There’s no user manual for GIT, only docs for the invdividual commands.

hg uses language very similar to Subversion, although some terms have different meaning. It introduces some more terminology specific to merging and branches, and it sounds confusing to me as a SVN user. Probably it clears out with practice.

In overall Mercurial looks more ‘human friendly’. It’s focused more on how we people think of history of documents and parallel changes (branches). It takes responsibility for book-keeping branches/merges, while in Subversion you need to keep track or identify start and end revisions in the branch you’re merging from. In SVN you need to find those start/end revisions by date, or by ‘svn log –stop-on-copy’ command. hg takes care of all that. Those were the ‘high level’ hg branches and merges. ‘Low level’ branches and merges occur all the time when pulling from other team members.

SVN has a URL for each subfolder/file in the repository – which covers all branches, tags, everything. hg has URLs but only for the main, public branch (tip or head?).

Niceties of Mercurial:

  • easy reverting of all subfolders and their files – ‘hg revert .’

  • easy pullback

  • little merges – everything you do is in your local repository. Then you merge it with changes of other people. Because merging is the daily bread, hg makes it as simple as possible

  • simple installation and administration. It only stores repository on file system, while SVN can use DB and FS.

  • history search by programmable filters via ‘hg bisect’ (logarithmic rather than sequential search)

The positives of being distributed

  • 0 day start

    • once you install locally, you can commit locally

    • works over SSH without setting any deamon/DB on the server, once you install hg on it

  • local searches over whole history – very quick

Drawbacks/complications:

  • update, merge are separate tasks. ‘hg update’ updates your local repository, but it doesn’t update your working directory – use ‘hg merge’ for that.

  • The simplest way to have ‘high-level’ branches is to have one repository for a branch. That’s OK locally, but if you want the branches to be stored on a server then developers need rights to create them and it gives extra work. hg supports several branches in same repository but it’s when the usage gets more advanced/complicated. But, it looks nicer/easier than keeping track of SVN branches (within same repository).

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: