i ran into this bug in 1.6.4 yesterday. has this been fixed yet?
thanks
On Jul 23, 12:15 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> Reto wrote:
> > 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/orxonoxIt 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.
>
> Small update:
> 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.
>
> Stefan
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
> ------------------------------------------------------http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr..._at_tortoisesvn.tigris.org].
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2385705
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-20 19:13:30 CEST
