It is really hard. I worked on a branch for a new feature maybe 2 months. The trunk is kept with some small enhancement and bug-fix. Today is the merge day. OMG, that is hard. I used the merge in Netbeans first. After 40 minutes I seem to get all the brown sign of conflicts out and committed it. Well, that is not so bad, I thought. But soon I discovered quite some new files are missing and some are not updated. Boom! I rolled things back to last reversion and recommitted. This time I tried to do it in Eclipse. Well, it seems more conflicts pop up and I guessed that Eclipse's SVN plugin was better. I was wrong after another half an hour. Still some files were showed updated but they are definitely old. What is wrong!
It turns out that neither one handles TREE-CONFLICTs well. And yes, it proliferates for my merge. And neither provides any good way to handle it. I have to done it one at a time in command line. SVN is really dumb for tree-conflict. I checked out a clean reversion again. I merged once. It stops at certain revision. I resolved conflicts (normal ones) in Eclispe. Then I tried to hand-mark those tree-conflict as resolved. And then I merged again. This time it progressed to some further revision with some new conflicts. I marked them resolved again, merged again. .... Five, six cycles later, I finally get to the HEAD. :) The stupid things about svn is that if I added one file and later removed it in the branch, merging stops at some revision with adding the file, then next time merging removes it. Odd price to pay with a revision system with historical approach.
That is really hard!
Note: A couple of days later, I found it missed a few files. OMG! (9/20)
