Question

In HgInit Joel basically states that Mercurial will make merges much much easier than Subversion.

Here's a typical scenario which leads to tons of conflicts in Subversion and makes concurrent work with the source code problematic. We have a function with many (say, 4) parameters that is called from numerous sites in the code. Now user A sees this mess and notices that actually those 4 parameters always come from the same class (say CSettings). Something like:

doStuff( settings->GetAddress(), settings->GetColor(), settings->GetIdiocy(), settings->GetWhatever() );

So he decides to refactor the code - pass one parameter and make the function retrieve the data from the class. So it becomes just:

doStuff( settings );

Meanwhile user B is completely unaware of that refactoring and he decides that he absolutely needs to add a 5th parameter to that function which (SUDDENLY) also comes from the very same class CSettings:

doStuff( settings->GetAddress(), settings->GetColor(), settings->GetIdiocy(), settings->GetWhatever(), settings->GetEvenMore() );

The point is both users change the very same lines of code in two completely different ways. Now the faster gun of them svn commits, the other one needs to svn update and resolve a ton of conflicts which requires a lot of manual labor.

How will Mercurial be better in this situation?

Answer 1

DVCS does actually improve things here. That's not to say this is ever a desirable scenario, but if it has to happen, I'd rather it happened to a project I have in a DVCS.

In a traditional centralised VCS the collision stops work almost immediately. It certainly stops work for user B, who is essentially unable to get back to his real job until he fixes this merge. But it may also stop work for users A and C, either because the merge resolution step takes a lock on the central repository, or because user B comes to them and insists they don't touch anything until he fixes the collision because he's scared of what will happen.

In a DVCS nobody needs to care about this until they want to. In most of these tools you can try an automatic merge, and if it doesn't work you can say "I don't have time for this, I will merge that stuff tomorrow, after I get this stuff working" and then continue using the version control system, just without a merge and thus without the changes you couldn't merge.

This also gives you (a hypothetical manager or senior developer) the breathing space to manage the problem. You don't have a horde of programmers in your nice quiet office demanding you do something (maybe that you fire user A) because they can't get any work done. Maybe you think this was the wrong time to refactor, or you feel user A should have consulted people first, maybe user B isn't keeping up with the team's decisions. The DVCS gives you more options for getting out of the mess too. In git for example, I might choose to retrospectively move user A's refactoring change into its own branch. That's "rewriting history" which is painful, but in a traditional VCS it's actually likely to lead to data corruption, and thus not really an option, in git it's just a few commands and an email to the affected git users explaining why they're seeing scary warnings and what to do.

Answer 2

what i first read in the cvs documentation is as true today as it was then:

CVS is not a substitute for developer communication

substitute scm-of-your-choice for cvs.

Answer 3

I think it's important to stress that Mercurial is not magic :-) So if there is a genuine conflict because two developers have edited the same line, then Mercurial and any other tool must flag this when merging. You will then have to resolve this using a merge tool.

However, all the systems are not equal when it comes to handling situations where there are no real conflicts. That is, some systems tells you that they have found a conflict when they really shouldn't.

Subversion is one such system: it cannot merge back a branch if you have renamed a file that was also changed on the trunk. Please see my answer at StackOverflow for a concrete example where Subversion fails and Mercurial wins.

Answer 4

I guess there is no chance for any system to handle that better. When two developers change the same line of code this has to be resolved manually anyway. This is just because no system can know of something like the meaning of the lines of code.

The best you can do is to look for an appropriate 3-way merging tool to help in this process.

Answer 5

Well, if an intermediate repo copy on each user's machine is desirable in the sense that they can keep committing to the intermediate "server" and not "inflict" the change on everybody else it does not change the basic premise that other coders in your team are still making changes to the code assuming nothings changed (as an example pointed out here). In SVN you don't commit fearing its repercussions, here you commit but no one sees it unless you push. How would this be desirable ?