There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy
What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".
From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited recently, SVN has gone a long way towards making merging a much easier thing. It is not foolproof, though, and I think it does not easily suffer users deviating from the intended use.
While I knew SVN quite well and had also tried Mercurial for personal projects in the meantime, I had never done a lot of branching in SVN prior to this project. There was quite a bit of trial and error and I got a lot of unexpected merge conflicts when I started.
Ultimately, though, I realized that everytime I got one (or some other issue), it was because I hadn't done things properly (aka "the SVN way" -- arguably, the proper version control way). I believe this is where the difficulty lies: you cannot do whatever you want in an unorganized way and expect SVN to work perfectly, especially with merges. Merges require rigorous discipline from the user(s) before they show their true power.
Here are things I've noticed are strong recommendations, if not requirements, for a clean use of merges:
- Use a recent version of SVN (1.6 and up in my opinion). More and more automation and checks are done for you.
- Use the default "trunk, branches, tags" structure and apply its philosophy (don't commit to tags). SVN won't check anything for you. If you use a tag as a branch (that's the state I found that project repository in), it can still work, but you need to be consistent.
- Know what branches are and when to create them. Same with tags.
- Keep side branches up-to-date with their source branch (usually trunk, but you can branch out from any branch technically). This is mandatory IF you want SVN to do auto-merges. SVN 1.8 actually prevents you from auto-merging if things are not up-to-date, and also if you have pending modifications in your working copy.
- Do "proper" commits. They should only contain modifications on a very specific concept. As much as possible, they should contain a small amount of change. You do not want to have a single commit contain modifications about two independant bugs for example. If you have already fixed both and they're in the same file, you should store away the changes of one bug so you can commit just the changes of the other first, then commit the second set of changes. Note that TortoiseSVN allows this easily through "Restore after commit".
- Doing so makes it possible to revert a specific independant set of changes AND makes it possible to only merge such a set into another branch. Yes, SVN allows you to merge cherry-picked revisions.
- If you ever use sub-branches (branching off trunk, then branching off that new branch), respect the hierarchy. If you update the sub-branch with the trunk or vice versa, you're in for some pain. Merges should be cascaded down or up the hierarchy.
- As much as possible, merge from the root of the branch. Otherwise, SVN will only keep track of the merges done for the sub-folder and when you do try to auto-merge from the root, you may get warnings about missing unmerged revisions. It's fixable by simply merging these from the root, but best avoid the confusion.
- Be careful which branch you commit to. If you use Switch to have your working copy point to various branches through time, be sure where you're committing to.
- It's especially bad if you really didn't want the change in that branch. I'm still not clear on that one, but depending on how you get rid of it / transfer it into the right branch (reverting, merging), you can get something messy. It's fixable, but you'll either have to merge revision by revision to avoid or immediately solve potential conflicts, or you'll have to fix a possibly more complex conflict after the auto-merge.
If you don't follow the above, you're quite likely to get conflicts. They're always solvable, but not terribly fun to spend time on.
Oh, one more thing about merging where, from all I've read and tried, SVN really sucks: deleted/moved/renamed files/folders. Apparently, SVN still cannot deal with a file being renamed, deleted or moved in one branch, and its original version modified in another branch... and then merging these together. It just won't know where the file went in one way, and will "forget" the changes in the other way. One change is obviously unsolvable (you either delete or change the file, can't do both), but applying changes to moved/renamed files should work and it doesn't. Hopefully this gets fixed soon.
So, all in all, is SVN merging easy? I guess not. Not in a carefree way, for sure. Is it bad? I don't think so. It only spits back in your face when you use it the wrong way and don't think enough about what you're doing.
Based on this, I can see why people might prefer Mercurial (for example) as it's a little more lenient about these things from my experience and had everything automated from the get-go (at least from the early versions I started with). SVN has caught up quite a bit, though, so it's not worthy of so much bashing anymore.