TortoiseMerge: Possible bug

Today I tried to range a of revisions from a branch back to the trunk, but I had already done so with a few other revisions before (same branch, also back to the trunk).

The merge worked fine as long as I didn't use TortoiseMerge to edit the conflicts. What happened:
There were about 4 or 5 ranges of revisions to be merged in the third or so a conflict occurred. The resulting text files (with "<<<<" and ">>>>") showed both versions correctly. However by editing the conflict with TortoiseMerge the working copy version was simply wrong (right side). It probably showed the last version from the range that was being merged when the conflict occurred.

As a result the whole file got kind of busted because it missed about the latest 15 revisions. Manual merge then got me the right results.

I'm using the latest 1.6.3 TortoiseSVN version and server side I believe we still have 1.4.x. The repository is at:
http://svn.orxonox.net/orxonox
It has public access so it is possible to make a checkout and merging (without commit of course) should work as well.

The exact steps were:
svn up trunk -r3316
Then I merged revisions 3270, 3272-3276,3279,3281,3285-3286,3288,3290-3295,3306,3310-3311 from branches/core4 back to the trunk.
The interesting conflict occurred with src/core/input/InputManager.cc. When you compare the version generated by SVN (with <<<< and >>>>) with the one shown in TortoiseMerge on the right hand side, you'll notice a difference.

I hope I haven't forgotten anything important, or else just ask. If merging doesn't work with anonymous access I could also get an account.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2372432

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-07-19 17:25:36 CEST