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.
Thanks!
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:
.../StatGraphDlg.cpp.merge-left.r23845
== `svn cat ^/trunk/src/.../StatGraphDlg.cpp@23845`
.../StatGraphDlg.cpp.merge-right.r23846
== `svn cat ^/trunk/src/.../StatGraphDlg.cpp@23846`
.../StatGraphDlg.cpp.working
== `svn cat ^/branches/1.7.x/src/.../StatGraphDlg.cpp@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
unrelated changes.
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
changes
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 :)
Thanks!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
