That's what I did:
Downloaded the binary installer from Collabnet (ahh, it's free registration -- that would make up another post about stupid registration procedures for so-called free softwares) and ran it: next, next, finish, all worked fine, exactly as a soft-core Microsoft-guerilla -- like me -- expects it.
I was eager to see this reintegrate-my-branch-without-screwing-the-mess-up-feautre in action, so quickly created a new repo, created a trunk, branched it, added a file in the branch, merged back to trunk, fine, merged revisions show in pale, revision graph is ugly but correct, so let's see the action: I modified the file in the branch, committed, and clicked merge/reintegrate in Tortoise and... ah, it says update the trunk working copy. I updated it, merge/reintegrate again... and halts with a red error stating a Tree Conflict.
I spent an hour playing with it, the situation is simple: the repository follows all merge-backs correctly, the Tortoise client displays them nicely, but for some reason, reintegrate doesn't work. At least, not as it should. I tried manual merging - and worked fine. Then another change in the branch, and reintegrate fails again.
Here is the morale: anything, that happens in the branch and affects tree, causes a Tree Conflict when reintegrating. Even, if that revision range has already been merged back to the trunk. Strictly speaking, deletion works fine, but renames are delete+copy, and copy causes the same as create, you are screwed up anyway.
I tried it many times, with imported repos and brand new ones, this way, that way -- all goes consistently wrong.
See the facts:
- Windows XP w/SP3 and all patches
- CollabNetSubversion-server-1.6.5-6.win32.exe
- TortosiseSVN 1.6.5 latest version
- using Apache to serve them all, but I don't think that means anything in this case
Steps to reproduce:
1. create your shiny new repo named 'xx'
2. create a <reporoot>/trunk folder in it
3. checkout trunk to c:/xx-trunk
4. create a file like 'apple.txt', add it, commit -- I guess one can safely skip this step
5. branch your trunk to <reporoot>/branch
5. checkout the branch to c:/xx-branch
6. add another file like killer.txt, commit
7. update xx-trunk -- though nothing happens here, your working copy's revision rises by two and that's needed
8. right-click on xx-trunk, Tortoise/Merge/Reintegrate - select <reporoot>/branch as "From URL" and click [Merge] -- voilá! killer.txt now appears in your trunk.
Note: I'm not sure what Merge depth means here. I tried it with different settings, but no change.
9. now, see your trunk's history, and see the new checkbox down there: Include merged revisions. If it's checked, you see revisions, that belong to the branch, but has already been merged into trunk. And the Lord said: thou shall be happy now and forever.
Note: I'm talking about branch and trunk here. These could be any two pathes in the repository. The reintegration feature is targeted at the typical scenario, when a branch forks off the trunk for some reason and later you want to "go back home" -- that means, you want to integrate all changes made in that branch back to your warm and safe trunk.
At the first time one merges, there used to be no problems. However, when you merge back the 15th time, and you had some revisions not merged back for some reasons, its very easy to miss some revisions, or worse: include a range more than one time. What is this case happens, God only knows. If you are not lucky, you will produce a tons of conflicts.
So, back to testing:
10. modify your killer.txt in the branch and commit
11. update your xx-trunk (see step 7)
12. now comes the hot lion: we click reintegrate on the working copy of the trunk and want it to include the change we made in step 10. No more, no less. And we want it without counting revisions, without subtracting one from the first revision number (in order to include the whole region) and without reading the whole svn book all over again. (Not counting those who have done it a hundred times AND never make mistakes anyway.) Well, they promised it, didn't they?
So it fails. It says: Tree Conflict. Like it wanted to add the killer.txt again. Instead of just making the diff from step 10.
Let's say, after step 10:
a) you deleted apple.xt
b) renamed killer.txt to dead.txt
and you did them in separate commits, just for simplicity. Here are your results after reintegration:
- apple.txt deleted -- ok
- killer.txt is still there -- wrong
- dead.txt is also there -- ok
- you have a Tree Conflict glued to your directory -- I'm not sure how to remove that
It's a bug. A BIG BUG. And it's not 1.5.0-pre-beta-use-at-your-own-risk, it's frankly a stable version. I really don't get it. I really want to hear something like 'Hey, you prick, that works this way: ...' or 'Your assumption of ... is wrong because ... '
Who will be the first enlightening me?