Are merges in subversion more difficult than in Team Foundation System?

Question

I'm used to using TFS, and my company is now switching to SVN for a new project (the main reason is to better incorporate our java & .Net codebase under the same source control).

I am given to understand merges in subversion are hard (Jeff mentioned this in his latest podcast).

1. What are the problems with subversion, when compared to TFS?
2. How to mitigate? (withing the bounds of subversion, or as Jeff proposed, choosing another source control)

One strong feature that TFS offers is its automerge capabilities (greatly improved in TFS2008, although not perfect yet). Most merges don't require any action by the user. Is that the same in subversion?

Update - an accepted answer here can only come from someone who has experienced big merges in both TFS and subversion, and can actually compare & contrast the two. Knowing that "merge in subversion is good" or "TFS is crap" doesn't really help me decide, because it's subjectve. If you can compare to other alternatives, great - it is helpful. But my focus is subversion vs TFS.

The target team size I'm interested in is 6-30 active developers.

Update 2 - is there anyone that would make the case that merges in SVN are in fact easier than in TFS (taking tooling into consideration)?

Answer 1

I'm not familiar with TFS, but until version 1.5, subversion's merge support consisted of little more than taking the diff of a (manually-specified) range of revisions, and applying it to another path in the repository. With version 1.5, merge tracking was implemented, but it appears to be rather complex with interesting edge cases.

If merging is critical for you, you may wish to consider one of the DVCSes that excel at merging, such as git or mercurial.

Answer 2

I don't think merges in subversion are hard at all for the common cases, have a look at examples like these. I have found merging delightfully simple and easy; although some co-workers complain about liking CVS more, others p4 etc. etc. I suspect much of it has to do with familiarity with other tools, not with technical superiority/inferiority.

It may be that more complicated (three-way) merges are harder, but question is whether ones in common use are those. Personally I consider complicated merges (and long-living branches, complex tracking of branches and merging strategies etc) smell of code rot (or I guess SCM rot). YMMV.

Answer 3

Somewhat off topic, but if the question of moving from TFS for your java developers is still up in the air, I would recommend you look at Teamprise. It is a tool made just for Java developers that use TFS. It gives a Java user most of the power of Visual Studio integration (and some things even better) inside eclipse.

http://www.teamprise.com/

(FYI, I am not affiliated with them in any way...)

Vaccano

Answer 4

I have used subversion for a very long time, and let me tell you, merging is horrible and absolutely broken. I have changed to mercurial, even though I have no use for the distributed stuff, just to get branching that works.

Elaboration, as requested To successfully merge in SVN you need(ed) to know the version number the branch was carrying, which is not that difficult to find as long as you are only doing a single merge back into the trunk. Unfortunately some times you need to merge several times (ie it turns out that to add a feature you first had to fix a bug) in to the trunk, or you are doing merging between different branches which makes it impossible to keep track of which version number belong to which branch and what has previously been merged.

The version of SVN I use is 1.5.1, so it should work with the new style development, though it appear as I missed that.

Answer 5

I have done big merges in both TFS and Subversion. The TFS codebase was a 1.5->2.0 branch of a SharePoint application with production changes merged into the 2.0 codebase. The SVN merge was a merge of new features from a fork into the baseline source.

You are already familiar with TFS so I'll spare you the details, other than to say that the changesets and TFS tools made the process very simple. We did get the TF14087 error due to an undelete issue but it was quickly resolved.

In SVN, the process was quite a bit more manual because we had to target specific versions of the files in SVN, and SVN did a diffmerge on files which did not allow us the flexibility we experienced with changesets in TFS (cases such as "not all changes in ChangesetA but all changes in ChangesetB"). We didn't have merge tracking at the time, nor was our source tree designed to support the best practices of SVN merge tracking.

I think now, with merge tracking in SVN, the process would be quite a bit simpler assuming you follow the best practices outlined by CollabNet. But bear in mind that TFS is a big product with really great GUI tools for managing your source, while SVN depends more heavily on the command-line, so this complicates things if you're used to working with the GUI.

Answer 6

There are pros and cons of all systems.

But one little useful note (that is close to off topic) is that a external powerful merge/diff program is often really useful. So whatever you choose make sure you have a nice 3-way merge tool around to help out when the automated stuff breaks.

BR Johan