6

Possible Duplicate:
Merging: hg/git vs. svn

I've heard/read that Git and DVCS's in general are better than Subversion and centralized version control systems. And one of the reasons I've heard for this is that merging is so much better in DVCS's than in centralized system.

What is the difference between the two when it comes to merging? What makes Git better than Subversion when you're re-integrating a branch, for instance?

Community
  • 1
  • 1
Brandon Montgomery
  • 6,924
  • 3
  • 48
  • 71
  • I think a lot of the "SVN merging debate" comes from DVCS aficionados. Merging is one of the things SVN improved a lot over CVS, but CVS' (deservedly) bad reputation might reflect on SVN. In our team we merge a lot in SVN, and I don't know of problems. – sbi Nov 18 '10 at 13:26
  • 2
    Very related: http://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy – kolobos Nov 18 '10 at 13:37

2 Answers2

5

It's not so much the fact that they're distributed, but more that they keep track of changesets rather than versions. (However, distributed systems usually work with changesets, while centralized ones often use versions; this is because distributed systems just won't work with a version-based approach, while centralized systems can get away with it).

Subversion says, OK, first I had this version and then I had that version. And then when it's time to merge, it takes the two versions, compares them, and makes educated guesses on how to combine them. Git, mercurial, and similar SCMs, say, OK, first I had nothing, then someone made this change and then someone else made that change, etc. When it's merge time, basically all they need to do is apply the changes in the correct order, correcting for line numbers here and there and taking file renaming into account, but that's basically it.

Subversion doesn't really have enough information to perform an intelligent merge: it only sees the differences, but not where they come from.

tdammers
  • 20,353
  • 1
  • 39
  • 56
  • 4
    Couldn't Subversion traverse the revisions to find the same information? – Lasse V. Karlsen Nov 18 '10 at 13:25
  • 2
    @Lasse: Of course it has. What's the difference between `r1` and `r2` if not the changes between `r1` and `r2`? That argument really escapes me. – sbi Nov 18 '10 at 13:28
  • 3
    Well, if Subversion only looks at the original file, and then the final result, it will have lost all the intermediate steps, where DVCS does at least use those steps to do the merge. But my question is just why Subversion couldn't analyze the intermediate revisions to find those steps. I'm still looking for a good explanation about where the magic in DVCS merging comes from. – Lasse V. Karlsen Nov 18 '10 at 13:30
  • Performance would be my guess. When you keep track of versions, traversing them all to find the changes is costly. – tdammers Nov 18 '10 at 13:54
  • 2
    I'll buy that, but then the argument isn't that DVCS is better than CVCS at merging, it's that the implementations we typically choose are better. In other words Git and Mercurial is better than Subversion, but Subversion *could* be just as good, if it just did things differently but still be a centralized VCS. – Lasse V. Karlsen Nov 18 '10 at 14:01
  • @Lasse: Because of Subversion notion of "branches" as folders (branching is copying), which is IMHO wrong and has wide-reaching consequences. – Jakub Narębski Nov 18 '10 at 14:13
  • 2
    There are a few bad design decisions in subversion, but they are not directly related to it being centralized. – tdammers Nov 18 '10 at 14:34
  • Git's object model is based on version snapshots, not changesets. See http://git-scm.com/book/en/v2/Git-Internals-Git-Objects – Max Nanasy Jan 22 '15 at 02:17
3

Linus torvalds did a talk on git, available on youtube and worth watching. In it, he dismisses all source control solutions but git, then explains why git is great.

Personally, I found git frustrating to get to terms with and I use SVN professionally every day. I think svn is fast enough and does branching & merging well enough for my needs.

But I'm no source control expert!

  • 2
    Well, he kinda explains that git *is* great, but not so much as to *how* git manages to be great. For instance, he says that git tracks the entire project instead of individual files. However, simple experiments with moving text to a different files parallel with someone changing it still gives me merge conflicts. – Lasse V. Karlsen Nov 18 '10 at 13:45