I am not happy with the way Subversion handles merges. It is probably the weakest part of Subversion. In fact, the post-1.5 method of actually tracking merge information is in many ways worse than before. In the pre-1.5 days, In the old days, I could usually do "svn log" and get the information I needed in order to perform the merge properly. But, the post-1.5 merge tracking leaves a lot to be desired.
One of the biggest complaints is that developers don't care when there is only a change in svn:mergeinfo in order for Subversion to do its job. What happens is a developer does a merge, expects four files to change, then sees 300 files "modified". It takes a while to realize the only change to 296 of those 300 files is that svn:mergeinfo was updated. Doing "svn log" also shows these svn:mergeinfo as "file modifications". It is just damn confusing. It would be helpful if Subversion could filter out this noise. I understand using svn:mergeinfo as a property to track merging, but it really turned out to be a pain. The other complaint is that Subversion's merge tracking isn't very good. Merging is difficult to do. There are many scenarios that you have to track, and some are mutually exclusive (divergent vs. convergent branching, reintegration, tracking changes when a "merge" isn't really done, but information in Branch "B" was put into the file in Branch "A", etc.) In most places I've worked, developers have stopped using merging, and simply copy the changes manually from one branch to another after Subversion started to do merge tracking. Much of this is due to Subversion having difficulty with merging (what if you are copying changes back and forth between two branches instead of making changes in one branch and "reintegrating" them in another?). But much of it has to do with the svn:mergeinfo noise. -- David Weintraub qazw...@gmail.com