Mercurial_ The Definitive Guide - Bryan O'Sullivan [113]
Subversion more or less gets away with not having a well-defined notion of a branch: which portion of a server’s namespace qualifies as a branch is a matter of convention, with the software providing no enforcement. Mercurial treats a repository as the unit of branch management.
Scope of commands
Since Subversion doesn’t know what parts of its namespace are really branches, it treats most commands as requests to operate at and below whatever directory you are currently visiting. For instance, if you run svn log, you’ll get the history of whatever part of the tree you’re looking at, not the tree as a whole.
Mercurial’s commands behave differently, by defaulting to operating over an entire repository. Run hg log and it will tell you the history of the entire tree, no matter what part of the working directory you’re visiting at the time. If you want the history of just a particular file or directory, simply supply it by name, e.g., hg log src.
From my own experience, this difference in default behaviors is probably the most likely to trip you up if you have to switch back and forth frequently between the two tools.
Multi-user operation and safety
With Subversion, it is normal (though slightly frowned upon) for multiple people to collaborate in a single branch. If Alice and Bob are working together, and Alice commits some changes to their shared branch, Bob must update his client’s view of the branch before he can commit. Since at this time he has no permanent record of the changes he has made, he can corrupt or lose his modifications during and after his update.
Mercurial encourages a commit-then-merge model instead. Bob commits his changes locally before pulling changes from, or pushing them to, the server that he shares with Alice. If Alice pushed her changes before Bob tries to push his, he will not be able to push his changes until he pulls hers, merges with them, and commits the result of the merge. If he makes a mistake during the merge, he still has the option of reverting to the commit that recorded his changes.
It is worth emphasizing that these are the common ways of working with these tools. Subversion supports a safer work-in-your-own-branch model, but it is cumbersome enough in practice to not be widely used. Mercurial can support the less-safe mode of allowing changes to be pulled in and merged on top of uncommitted edits, but this is considered highly unusual.
Published versus local changes
A Subversion svn commit command immediately publishes changes to a server, where they can be seen by everyone who has read access.
With Mercurial, commits are always local, and must be published via a hg push command afterwards.
Each approach has its advantages and disadvantages. The Subversion model means that changes are published, and hence reviewable and usable, immediately. On the other hand, this means that a user must have commit access to a repository in order to use the software in a normal way, and commit access is not lightly given out by most open source projects.
The Mercurial approach allows anyone who can clone a repository to commit changes without the need for someone else’s permission, and they can then publish their changes and continue to participate however they see fit. The distinction between committing and pushing does open up the possibility of someone committing changes to their laptop and walking away for a few days having forgotten to push them, which in rare cases might leave collaborators temporarily stuck.
Quick Reference
Table A-1. Subversion commands and Mercurial equivalents
Subversion Mercurial Notes
svn add hg add
svn blame hg annotate
svn cat hg cat
svn checkout hg clone
svn cleanup n/a No cleanup needed
svn commit hg commit; hg push hg push publishes after commit
svn copy hg clone To create a new branch
svn copy hg copy To copy files or directories
svn delete (svn remove) hg remove