Stefan Küng wrote:
> Reto wrote:
>> 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.
>
> I've tried to reproduce this, but I can't figure out what's wrong with
> the merge (if it really is).
>
> If I edit the conflict *during* the merge, everything seems ok.
> If I edit the conflict after the merge (i.e., click on "resolve later"),
> it too looks ok to me. TMerge shows the conflicted lines correctly, I
> can't see any difference between what TMerge shows and the conflicted
> lines in the file.
>
> Can you maybe provide more information on what you see and what you
> would expect? Maybe some screenshots of TMerge?
>
> Stefan
>
>
I merged again and made some screenshots:
So I make the checkout (http instead of https to do it like you) and
then merge with "Merge a range of revisions", copy&paste my list from
the mail (and remove the white space) and do it as non-interactive
merge, so I can do something else in the meantime.
The merge then looks like this:
http://svn.orxonox.net/webdev/develop/tortoise_temp/TMerge_1.jpg
Now I go to that InputManager.cc file and hit "edit conflicts" and merge
the conflict like this:
http://svn.orxonox.net/webdev/develop/tortoise_temp/TMerge_3.jpg
After that I hit "save" and "resolved" in TortoiseMerge (or should I not
hit save and that's my problem in the first place?). Anyway have a look
a the class's constructor arguments (while merging):
http://svn.orxonox.net/webdev/develop/tortoise_temp/TMerge_2.jpg
Checking the changes with "Diff" shows:
http://svn.orxonox.net/webdev/develop/tortoise_temp/TMerge_4.jpg
Now, I do the same steps but resolve the conflict manually with vim and
then the InputManager constructor arguments look as they should:
http://svn.orxonox.net/webdev/develop/tortoise_temp/TMerge_5.jpg
Notice the difference (it's more than just the arguments).
The c'tor argument change happened in r3291 which was after the conflict
occurred (from an svn history point of view).
I hope you reproduce this.
Reto
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2372884
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-07-21 11:35:34 CEST
