On 30.01.2013 03:17, Julian Foad wrote:
> Stefan Küng wrote on 2013-01-27:
>> using a build from the svn trunk (as of r1439016), I've discovered a few
>> problems when merging.
>> svn co -r23862 https://tortoisesvn.googlecode.com/svn/branches/1.7.x/src tsvnsrc
>> cd tsvnsrc
>> Now for the merge:
>> svn merge -c23846,23862 https://tortoisesvn.googlecode.com/svn/trunk/src
>> if you hit 'e' to edit the file, remove the conflict, save it, exit the
>> editor, then hit 'r' to mark the conflict as resolved: svn reports still
>> a conflict and aborts the merge. Even though I explicitly told it that I
>> resolved the conflict!
> Hi, Stefan K.
> I can reproduce that exactly. Thanks for the precise recipe. I'll work on this next.
Using r1440553, this now works. Haven't tested with the CL client but I
don't get conflicts anymore when using TSVN.
>> When not using the CL client but TSVN to do the merge, there's another
>> issue: I'm using a temp file to save the merge result and pass that back in
>> the svn_wc_conflict_choice_t struct of the callback. Not sure if that's the
>> reason for the problem, but by doing that, svn leaves the conflicted files
>> (merge-left.r23845, merge-right.r23846, working) behind and does not remove
>> them. That wasn't the case before.
> After r1440193, that should be fixed. Can you test that for me please?
Yes, it's fixed now.
>> now revert everything, redo the merge command.
>> This time, hit 'p' to postpone the conflict resolving.
>> Note that again, only r23846 is merged, the second revision isn't even tried
>> to be merged. This makes it very, very time consuming to merge something because
>> you have to restart the merge over and over again instead of just doing the
>> merge and then deal with the conflicts.
> I can reproduce that too and will work on it next.
>> But that's not the only issue:
>> The files merge-left.r23845, merge-right.r23846 and working all contain not
>> just the changes of the merged revision but all changes up to that revision.
> Can you check that again please? Your description of what you expect is not clear to me ("all contain [...] the changes of the merged revision"?), but in my testing the content of those three files are exactly what they should be -- that is:
> == `svn cat ^/trunk/src/.../StatGraphDlg.cpp_at_23845`
> == `svn cat ^/trunk/src/.../StatGraphDlg.cpp_at_23846`
> == `svn cat ^/branches/1.7.x/src/.../StatGraphDlg.cpp_at_23862`
> That is true when I do the merge using a build of svn r1440193 and also with r1439016. I'm testing on an Ubuntu GNU/Linux system.
Not sure what changed exactly, but now it's much better: while the 3-way
merge tool (TortoiseMerge) still shows diffs for unrelated revisions
(that's expected), it can now merge those files without applying those
TortoiseMerge uses the diff functions from the svn library so I guess
this got fixed as well.
>> Again, this wasn't what happened before. And this causes big problems
>> when using an UI tool to resolve the conflicts because those other
>> are of course also applied when saving the file, basically
> resulting in a
>> merge that does way more than what was asked for.
> I was able to run a graphical 3-way merge tool (kdiff3) on the three files (merge-left, merge-right, working) and graphically resolve all the conflicts -- the first one (the one that conflicts) manually, the rest (which don't conflict) were resolved automatically by kdiff3.
And "the rest" is what didn't work before: the auto-resolving lead to
all those changes getting applied to the file in the working copy. If
you look at all those changes you'll see that only two blocks actually
got changed in the specified revision, all other blocks were changed in
unrelated revisions (which haven't been merged).
But it works now. Which means you made me very happy :)
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
Received on 2013-01-30 19:54:03 CET