Re: problems with merging

[Julian Foad <ju...@btopenworld.com>]

Stefan Küng wrote on 2013-01-30:

> 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
>>>  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!
>> 
>>  I can reproduce that exactly.  Thanks for the precise recipe.  I'll 
>> work on this next.

I have filed <http://subversion.tigris.org/issues/show_bug.cgi?id=4316> to track this.

> Using r1440553, this now works. Haven't tested with the CL client but I 
> don't get conflicts anymore when using TSVN.

This doesn't yet work in the command-line client (trunk@1443825).

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

We previously decided that if one revision range within a merge raises conflicts, then (assuming they aren't immediately resolved) the merge should abort rather than go on to try to merge the next revision range.  That is because if we continue, and try to merge another change into a nodes that is conflict, we can't do so and we can't even properly record what happened.  (It seems like too big a task to design a system that would handle it properly.)

What I would like to see happen here is:

  * The first revision range of the merge raises one or more conflicts; you postpone resolving them.

  * The merge errors out, telling you how to continue the merge after you resolve the conflicts.

    - If it's a mergeinfo-aware merge, repeating the same merge should work.
    - Otherwise, Subversion need to tell you what revision range(s) still need to be merged.

    - If it's the command-line client, this info shall be in a text message.
    - For API users, this info shall be in a data structure.

I am working on that.

Does that sound OK?

- Julian