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 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.