Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
I’m a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?

Every once in a while, you hear someone saying that distributed version control (Git, HG) is inherently better than centralized version control (like SVN) because merging is difficult and painful in SVN. The thing is, I've never had any trouble with merging in SVN, and since you only ever hear that claim being made by DVCS advocates, and not by actual SVN users, it tends to remind me of those obnoxious commercials on TV where they try to sell you something you don't need by having bumbling actors pretend that the thing you already have and works just fine is incredibly difficult to use.

And the use case that's invariably brought up is re-merging a branch, which again reminds me of those strawman product advertisements; if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)

So, discounting the ridiculous strawman use case, what is there in SVN merging that is inherently more difficult than merging in a DVCS system?

share|improve this question
I am yet to work in an environment where they have months long branches being merged and they use distributed version control. The only places I have worked at that do such long lived branches used TFS/Subversion. I expect that such long lived branches would be difficult to merge with DVCSes too. –  Oded Oct 26 '12 at 19:23
@MasonWheeler I'm puzzled. What do you use a VCS for, then? I've seen and read that one (of the many) recommended practices is to have feature branches. Merging back to trunk is mandatory in that case. Or did I misunderstand something? (yes, the tree metaphor breaks, but it wasn't all that useful to begin with IMO) –  Andres F. Oct 26 '12 at 19:36
@MasonWheeler: I think you're taking the tree analogy a bit too literally. –  whatsisname Oct 26 '12 at 19:43
@MasonWheeler how many different development environments do you have experience of, if you've never heard of merging back to trunk? Some shops have stable trunk and experimental branches, in which case cherry picking successful featurs back to stable is a regular event. –  itsbruce Oct 26 '12 at 20:01
show 16 more comments

marked as duplicate by Earlz, Mark Trapp, Walter, MainMa, jk. Oct 26 '12 at 23:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

up vote 5 down vote accepted

It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.

I don't follow svn very closely, but my understanding is those particular technical issues have been fixed in recent versions. However, it wasn't fixed early enough to dispel the myth, and people who tried DVCS for the merges have stuck with it for other reasons.

share|improve this answer
add comment

if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)

And therein lies the source of your confusion and the whole problem in general.

You say that merging branches is "fundamentally wrong and silly". Well, that's exactly the problem: you're thinking of branches as things that shouldn't be merged. Why? Because you're an SVN user who knows that merging branches is hard. Therefore, you never do it, and you encourage others to not do it. You have been trained to avoid merging; you've developed techniques that you use to avoid merging.

I'm a Mercurial user. Even on my own projects, where I'm the only developer, I merge branches all the time. I have a release branch, which I put a fix into. Well, I merge that back into the main-line so that the fix goes there.

If I were using SVN, I would adopt a completely different structure of the codebase. Why? Because SVN makes merges hard, and therefore you develop idioms and techniques to avoid doing complex merges.

DVCS's make complex merges easy because they are the default state. Everything is a branch, more or less, in a DVCS. So the entire structure of them is built from the ground up to make merging easier. This allows you to develop a workflow that uses merging on a daily basis, rather than the SVN workflow where you never use merging.

The simple fact is this: you should approach a DVCS in a different way than SVN. You should use the proper idioms for these very different kinds of version control systems. In SVN, you adopt idioms that don't involve merging because merges are hard. In DVCS's, you adopt idioms that frequently use merges because they're no big deal.

Right tool for the right job.

The thing is, the merge-focused workflow is a lot nicer and easier to use than the SVN-style workflow where you don't merge things. It's easier to see when something from the release branch was brought into the dev branch. It's easier to see the various interplay between branches. It's easy to create test branches for things, then clip them off if the test doesn't work. And so on.

Really, Joel explains this a lot better than I can. You should have a good read of that.

share|improve this answer
On the contrary, I've never been "trained to" avoid merging branches. It's just something that honestly never occurred to me in the first place until I started hearing DVCS people talk about it, and my immediate reaction was (and still is) "what, are you crazy or something?" –  Mason Wheeler Oct 26 '12 at 20:51
@Mason: How is that not training? You were trained to use SVN in an SVN style. And the SVN style is to not use merging. Thus, you were trained to not use or even consider merging things. That's why it never occurred to you; because you used a system that makes it difficult. –  Nicol Bolas Oct 26 '12 at 20:53
There's a big difference between "not trained to" and "trained not to." –  Mason Wheeler Oct 26 '12 at 20:53
@MasonWheeler: No, there isn't. If you are not properly taught how to do something, then you are implicitly trained to not do it. It isn't in your repertoire of idioms you can employ to solve a problem. Therefore, you cannot use it to solve problems. The effect is no different from being told not to merge, because even if you wanted to, you don't know how. The way you offhandedly dismiss a good argument as "the same tired old ground" is evidence of this. You don't think of merging as a tool; you think of it as the exception or something unusual. Something to be questioned rather than used. –  Nicol Bolas Oct 26 '12 at 20:56
I never said that merging is something to be questioned. Merging is very useful, when used properly. What I said is that re-merging an entire branch is doing it wrong, and if people have trouble with that, it's not SVN's fault; it's because they're doing it wrong. (And what exactly is wrong with "questioning rather than using" anyway? The way you say that, almost make it sound like you think anyone who disagrees should just shut up and drink the Kool-Aid.) –  Mason Wheeler Oct 26 '12 at 21:08
show 3 more comments

I've done a fair bit of SVN merging -- including having long running development and release branches. By and large I survived. Merging is always tricky, but with DCVS the downside is not horribly bad -- everything is local so just update to a known good revision and keep going. Whereas with SVN alot happened on the server side so recovery was ugly -- usually it involved wiping out the local copy then checking out a new clean branch to try it again. Wasn't bad in my case -- a gigabit connection to the SVN box helps. But we had some contractors who had lots of trouble with this as they were on slow connections so anything took forever, including merges.

share|improve this answer
add comment

Yes, I do that too. I currently have 12 VMs for different versions (branches) of the project I'm part of at work. When I have to fix a bug in an older version, I fix the bug, then merge that commit into the branches for newer versions. But that's now re-merging an entire branch, which is what I'm talking about here.

Here lies one of the very nice things about git. It's not inherit about DVCS, it's just something git excels at. You can merge specific revisions from any branch into another branch. It basically just takes the diff and applies it to the other branch, but does tracking and is much more automatic.

So, if you have branch 2.0 and branch 3.0 and discover a bug in 2.0, you can then fix it in 2.0 and take the set of revisions which resolve it and merge only those revisions into the 3.0 branch. I don't believe SVN has any way to do this other than manually taking the diffs for each revision and applying them

Of course, the auto-merge algorithm also appears to work a lot smoother and git was built from the ground up on the "make a branch for all the things" model, so branching is just really smooth and easy in it. It just seems natural to branch often with how lightweight it's branches are

share|improve this answer
Also, I'd imagine that mercurial has similar functionality –  Earlz Oct 26 '12 at 20:40
Actually, you can do the exact same thing in SVN. I do it all the time. The SVN Merge command can pull a revision (or range of revisions) from a different branch and apply it to your working copy, and then you commit it. –  Mason Wheeler Oct 26 '12 at 20:40
@MasonWheeler Keep in mind that a lot of the anti-svn sentiment was directed to versions prior to 1.5 (when svn got merge tracking). And of course a lot of it is just pointless fanboyism... –  Yannis Rizos Oct 26 '12 at 20:42
@MasonWheeler see also stackoverflow.com/a/4215199/69742 That post boils down to DVCS keeps track of change-sets not versions. Change-sets are inherently easy to take and merge... versions not so much because they require context –  Earlz Oct 26 '12 at 20:44
@MasonWheeler oh and this one: stackoverflow.com/questions/2471606/… –  Earlz Oct 26 '12 at 20:47
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.