> 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
>> 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?
> 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:
> Now I go to that InputManager.cc file and hit "edit conflicts" and merge
> the conflict like this:
> 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):
> Checking the changes with "Diff" shows:
> Now, I do the same steps but resolve the conflict manually with vim and
> then the InputManager constructor arguments look as they should:
> 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.
I can reproduce the problem and you're right, something is completely
wrong here. TSVN tries to solve the conflict with TMerge using the files
the svn lib produces during the merge (filename.rXXX, filename.rYYY,
filename.working), and the filename.working file is the one that's IMHO
not right and causes the wrong result.
I have to investigate this further, but I may have to report this on the
svn list since it really seems to me that the .working file is wrong.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-07-23 18:15:52 CEST