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
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!
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.
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.
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
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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
Received on 2013-01-27 16:06:50 CET