SVN eclipse plugins. Subclipse and Subversive. Conclusion

As I've blogged here before, there are two SVN plugins available for eclipse, subclipse or subversive. We started using subclipse because on balance it seemed to have most supporters. So we used that for a few weeks.
I should explain that we use branches extensively in the development process we use and so we also have to merge these branches back to the trunk. The merging facility of our chosen plugin becomes perhaps one of the most vital parts since this is the trickiest operation and you need all the help you can get!
Using CVS (as we did before SVN) the CVS process within eclipse (I won't say plugin because it is part of the core eclipse build) creates a tag of root_branchname when you create the branch and then when you come to merge defaults to merging from that tag to the current HEAD revision. In the currently, SVN requires you to identify the revision number prior to the root of the branch as the source of the merge. This is more fiddly than I would like, with no defaults and every chance of an inexperienced developer getting something wrong.
Finding the source revision was not always straight forward on some machines we had to use tortoisesvn to look this up as subclipse seemed to be unable to list it correctly. Not only do you have to select the source revision in the branch but also the target revision in the trunk. The target revision is 99.9% going to be the HEAD revision of the TRUNK but this is not the default so you have to remember to set that as well. The merge is always carried out, even when there is a conflict. In CVS you had the chance to review and edit conflicts prior to the merge being done.
These issues made me take a second look at subversive. To start with it seemed a better plugin. You can always find the source revision although in principle the same issues of having to get this right remain. When you merge the merge is not carried out rather you get to review each change and copy these over one by one and then mark each merged file using 'mark as merged'. For small merges this works well, but for larger ones or for branches that have lived longer (time apart from the trunk) there may be a lot of changes in any given file - some have happened on the branch and some on the trunk. Here a major subversive flaw appears - the conflict editor view does not distinguish which changes have happened on the branch and which are from the trunk. This is vital to a complex merge, since you want to focus on the branch changes and be able to assume that changes already on the trunk are good (reviewed by someone else). Subversive also had some 'features' related to how you merged folder trees you had to select the folders beneath the top folder rather than the the top folder else it took a very long time to merge. These issues finally drove me back to subclipse. I'm more used to the selection of revision numbers now and my clean install always seems to be able to list the revisions clearly. Best of all the conflict editor clearly colours the changes black for changes on the trunk, blue for branch changes and red for branch changes that conflict.
The next release of SVN promises better merge control from the repository so these issues may all vanish.