Mercurial vs. Subversion

From APIDesign

Revision as of 04:30, 10 April 2009

Mercurial vs. Subversion

One side note in the chapter 13 compares behaviour of Mercurial and Subversion. A curious reader sent a comment:

Page 241: In the scenario described Subversion behaves the same way as Mercurial,

so it would not be possible to checkin changes without first synchronizing against

the HEAD revision (assuming checking goes to HEAD). See, for instance,

Subversion FAQ, question

I'm trying to commit, but Subversion says my working copy is out of date?, answer 3.

Looks like sometimes the svn up is needed. However not in the regular workflow. I've just tried:

# create a new file as user A:
svn co file:///tmp/svn/r/
echo Hi. >readme.txt
svn add readme.txt
svn ci -m "adding readme.txt by user A"
 
# create another new file as user B:
svn co file:///tmp/svn/r/
echo >b.txt
svn add b.txt
svn ci -m "Adding file b.txt from user B"
 
# now, as user A change the readme file, without updating
# e.g. without knowing that there is the b.txt file:
echo Hello >readme.txt
svn diff
svn ci -m "Changing content of file readme.txt as A, without updating to B's latest version"

The significant difference between Subversion and Mercurial is really there. Subversion lets the user A integrate changes without knowing what the final state after the integration will be. Seen from rationalistic point of view, this is not correct at all.

Mercurial would refuse such integration asking the user A to svn update to latest version of the repository first. This is the correct behaviour. However it is not really clueless.

Enormous majority of developers I know is complaining about such Mercurial restrictions. This is another example of correct but complex behaviour. Such correctness is reached at the expense of usability. Nice illustration of what can happen when one strives to make an API correct while ignoring other aspects of Good API.

Implicit Merges

As parren wrote the cause why Mercurial work flow is more complex lies in the concept of explicit merges.

In case of conflict Mercurial would record the two changes as separate heads (implicit branches). And it would not allow pushing both to a central repo without a prior merge (by default).

What typically bothers people is they need to merge the two heads to combine their effects. Which is, again, correct, but may seem to clutter history. So you can rebase (Jaroslav's note: rebase works only in git, doesn't it?), if you prefer, explicitly emulating what Subversion implicitly does.