[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: problems with merging

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 30 Jan 2013 02:17:42 +0000 (GMT)

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.

> 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?

> 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_at_23845`
  .../StatGraphDlg.cpp.merge-right.r23846
  == `svn cat ^/trunk/src/.../StatGraphDlg.cpp_at_23846`
  .../StatGraphDlg.cpp.working
  == `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.

> 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.

- Julian
Received on 2013-01-30 03:18:18 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.