On Tue, Feb 21, 2012 at 04:48:12PM -0800, Rick Ramstetter wrote:
> Hi all,
>
> A question regarding the handling of multiple conflicts while
> postponing conflict resolution across multiple merged commits.
>
> Let's say I merge two commits from trunk to a branch:
> $ cd /pathto/branch
> $ svn merge svn://repo/trunk -c 1,2 --accept=postpone
>
> Each of those merged commits (c1 and c2) causes a content (aka "Text")
> conflict in some file, "SomeFile."
> At this point, I believe SVN has merged c1, discovered a conflict,
> postponed that conflict, and continued to merge c2 onto the conflicted
> SomeFile.
>
> If I run:
> $ svn resolve --accept=theirs-conflict ./pathto/SomeFile
>
> ... Then I'm left in a situation where SVN has marked the conflicts as
> resolved ("svn status" reports no conflicts).
> Unfortunately, after running the above "svn resolve" a conflict does
> still exist. Opening up SomeFile in an editor, conflict markers are
> plainly seen.
> I believe this is because SVN has only resolved one of the two conflicts.
>
> Another SVN user bumped into this situation here:
> http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=98194&dsForumId=1065
> (subject: "multi-part merge with conflicts does not bail out with an
> error message")
It is possible to merge into conflicted files, as Mark Phippard explained
in his response to the post you linked to:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=98947
Some conflicted items are always skipped. If memory serves me right
this only applies to tree-conflicts, though.
> Is any related development in progress or in planning? More
> specifically, will "svn resolve" ever be able to resolve multiple
> overlaid conflicts?
Some items listed on the project's roadmap presume more advanced conflict
handling than Subversion has now: http://subversion.apache.org/roadmap.html
In the grand scheme of things, Subversion really needs a better conflict
meta-data store, and a much better resolution UI. The current situation
is inadequate for complex branching and merging. Merge conflicts cause
way too much pointless manual labour, especially with tree-conflicts.
Many ideas have been floated. Some notes have been written but I doubt
they are final in their current state:
https://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/conflict-ui
https://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/conflict-storage
> Does any way currently exist to achieve this functionality (besides
> serially merging commits)?
Usually people do verify changes before commit anyway, right? :)
Or they have some kind of continuous integration setup that will
catch commits which break the code with conflict markers.
So this shouldn't really be a problem for most people because the
problems won't go unnoticed and someone will be able to fix them.
I assume you are trying to automate merges in some fashion so you
cannot manually check the results before commit? Or you have some
use case where you cannot notice if something has gone wrong at all?
I would guess that a small change in the default behaviour of 'svn merge'
might help you a bit. Suppose 'svn merge' refused to merge into a working
copy which contained conflicted items, with a new command line switch
--allow-conflicts to override this restriction. In your example, this
would make the second merge bail out and require that the first conflict
is resolved first, unless the user explicitly overrides this.
I would support such a change unless someone can show that it significantly
hurts some existing valid use case. Similar changes have been made in the past.
For example, in Subversion 1.7 merges into mixed-revision working copies
were disabled by default to prevent some spurious tree conflicts.
