11

I'm getting started with SVN and so many sources say that merging is very difficult in SVN as compared to DVCS tools. The most recent questions I could find here on SE are from 2012.

Sometimes there's a mention that the reason is that SVN prior to v1.5 didn't have metadata, but SVN is at version 1.8.9 now.

Given that SVN is now much more mature than v1.5, and especially the fact that we didn't use SVN 1.5 so we don't suffer from the mentioned lack of metadata -- is there still much validity in those arguments against SVN?

I understand that DVCS has a completely different approach which is often more desirable, but for those who "must" ues SVN for whatever reason, merging isn't really "hell" anymore, is it?

Community
  • 1
Torben Gundtofte-Bruun
  • 572
  • 6
  • 17
  • 3
    @TorbenGundtofte-Bruun - I don't have the time right now to give such an answer, but I will say "don't fear SVN." It has limitations, but so do DVCS's. – kdgregory Aug 08 '14 at 13:04

2 Answers2

15

It works fine if you stick to the simple cases, but there are some complex ones that don't.

The limitations I can think of:

  • It can only find the most recent ancestor if it is on one of the branches involved. So if you create branches/this and branches/that both from trunk and then try to merge branches/this to branches/that, it will not know what to do. Which means you can only merge branch to or from it's parent. You may run into this if you start two feature branches and later realize that the features are interdependent and need to combine them.

  • While it claims it can track renames, merging branches when files were moved on one side and modified on the other does not always find the right files to merge and manually fixing it up is somewhat tedious as it does not leave the necessary information around anywhere at hand.

  • Added files sometimes cause spurious conflicts on later merges.

  • Since subversion does not have separate concept of branch, you can merge only a subtree of a project and that can lead to big mess pretty quickly. It is strongly recommended to take care to always merge complete branches. Unfortunately for some reason sometimes the merge info properties appear on subdirectories even if they seem superfluous and the merge was correctly done to the whole branch.

  • Last but not least it is slow. Merges on a project of any serious size often takes minutes where most DVCS can do it under a second.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • +1, great answer. The point regarding the common ancestor is something I'll have to look out for. Do you have any references for these facts? – Doval Aug 09 '14 at 13:21
  • 1
    @Doval: Experience. – Jan Hudec Aug 09 '14 at 18:17
  • possibly also worth mentioning that svn dosen't have a separate concept of tags either – jk. Aug 11 '14 at 08:37
  • Regarding your first bullet (thanks for a very clear explanation!) could that not be solved by using an accumulation branch that has the same branchpoint as the feature branches? (based on [Vance98](http://vance.com/steve/perforce/Branching_Strategies.html)) Does the problem only really happen when the two feature branches have different branchpoints? – Torben Gundtofte-Bruun Aug 12 '14 at 08:32
  • @TorbenGundtofte-Bruun: The most recent common ancestor does not have to be a branch point. You can find it yourself and tell subversion to apply changes between specific peg revisions. But the problem is that it's a lot of work and you have to realize you have to do it, because subversion does not necessarily throw up it's hands saying it can't merge. Instead it can find a common ancestor that's not most recent and generate lots of conflicts. – Jan Hudec Aug 12 '14 at 10:46
1

From my experience, merging in SVN was 'fixed' in version 1.6. I work in both Mercurial and SVN, and since version 1.6 of SVN, merging seems to be about the same amount of work on both platforms. The one exception might be that you have to remember to provide the --reintegrate option when merging from a branch back into the trunk using SVN.

This is only my operational experience. I don't know anything about the internals of SVN.

Charles E. Grant
  • 16,612
  • 1
  • 46
  • 73
  • 2
    1.8 can finally detect the "reintegrate" case itself, fortunately. But that only takes care of most recent common ancestor on local or remote. It still can't find it on third branch. – Jan Hudec Aug 08 '14 at 21:58