1

I have just read Joel's blogpost concerning distributed version control systems and can't understand the main idea. He says that SVN thinks in terms of versions while Mercurial thinks in terms of changes. And, according to Joel, it solves merging problems.

I heard this idea several times and still haven't conceived it. As I know, SVN's merging mechanism is based on changes (diffs) too. So what is the difference? I have no experience with distributed version control systems but I actively use SVN branching/merging and had no serious problems with it. Of course there are merging conflicts sometimes (when one piece of code was changed in both branches). But I see no way how this problem can be solved automatically by some kind of control version system.

SiberianGuy
  • 24,674
  • 56
  • 152
  • 266
  • 1
    The difference is the fact that modern DVCS record a full DAG of the changes, while afaik svn only records linear history (or a tree) and doesn't properly record merges. – tonfa Jun 17 '10 at 08:41
  • 1
    See http://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy, and the other links mentioned in http://stackoverflow.com/questions/2850996/mercurial-vs-subversion-whose-performance-is-better/2851020#2851020 – VonC Jun 17 '10 at 09:09
  • Joel's explanation is incorrect. As tonfa said the key idea here is using DAG of revisions in modern DVCS. – bialix Jun 18 '10 at 04:49
  • Subversion does record merges since version 1.5. The problem is not using a DAG or not, the real problem is that Subversion has long-standing bugs in it's implementation of merges. See this answer: http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2486662#2486662 – Martin Geisler Jun 19 '10 at 20:54

2 Answers2

1

The thing you are talking about with SVN is that some kind of tree conflicts couldn't be handled by Subversion and the merge will fail. In comparsion to git, hg and bzr it is true git, hg or bzr can handle these situations SVN at the moment doesn't. I recommend to read about the bachelor study which has been made and of course in the mean time some of these problems have been solved.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
0

I'll compare SVN to Mercurial, since this the only DVCS I've used so far. SVN uses files and makes copy of each file for each next version, while Mercurial assemples change sets. You have your complete file version 1.0 in SVN and you have another copy of your complete file version 1.1. In Mercurial you have your complete file once in version 1.0. Then you have a rules like "add 2 lines here and remove 3 lines there" to produce version 1.1. Mercurial goes through the whole history and applies the changes to your local copy during the update, but it doesn't store anywhere your complete file version 1.1.

However, the problem you described is not solved technically in Mercurial as well. I tried a very simple example: let two people add simultaneously one line at the end of one and the same file. The first one commits and pushes without problems. The second one needs to pull and update first, to take the latest change. And here is a merge conflict, which is annoying! Mercurial does not know if the second person wants to add one more line or wants to modify the line, just added by the first person. It is the same like SVN here - you have to merge manually... So, no magic at all :)

You can read the http://hginit.com/ for more info.

m_pGladiator
  • 8,462
  • 7
  • 43
  • 61
  • 1
    The first part of your answer is technically incorrect. SVN stores only diffs ("add 2 lines here and remove 3 lines there") just like Mercurial. SVN storage is very efficient. This is actually one of the things that Mercurial and SVN have in common. – Jim Hurne Jun 17 '10 at 09:35