Re: Merge conflict resolution

Hi,

Daniel Rall <dlr@collab.net> wrote:
> Hello Subversion IDE developers. I'm currently working on building
> Merge Tracking support for Subversion. As part of this journey, I've
> discovered that writing merge conflict markers into a file isn't
> conducive to a friendly user experience when applying multiple
> revision ranges during a single merge operation (or otherwise, for
> that matter :). I need to allow for a better way of handling merge
> conflict resolution in Subversion, and I'd like your help in assuring
> that this is designed from the ground up with Subversion IDEs in mind.
>
>
> Background:
>
> While conflict markers might not currently seem like much of a problem
> to most people (at least, to those not grumbling that Subversion is
> "corrupting their files"), Merge Tracking really complicates things.
> In today's Subversion, we apply only one revision range during any
> merge operation. With Merge Tracking, we may apply multiple revision
> ranges during a single merge operation, a rather fundamental
> difference with many ramifications. Once a file has a merge conflict,
> we have to stop applying revision ranges, meaning that we might apply
> only a portion of the revisions requested for merge by the user.
> Improved merge conflict resolution handling will really help address
> this user experience.

Currently if there is a merge conflict, we have four files: the file
with conflict markers, conflict_old, conflict_wrk and conflict_new.
I think the standard (gui) way is to launch a 3 way merge with the 3
conflict files, completely ignoring the file with the conflict markers.

I would expect that the (non interactive) merge procedure will not change.

If merge tracking allows multiple conflicts with differnt merge ranges
svn should stop after the first conflict and write the four files like
now. It should store any unmerged range, whatever infomration is required
to restart the merge later with the next revision range. Merging of this
file stops here for now.

When the user "svn resolved" the first conflict, svn should take the stored
information to continue the merge. If no other conflict shows up, fine.
If another conflict shows up, stop and restart again after the user also
resolved this conflict.

> Requirements:
>
> - Allow merge conflicts to be resolved during application of a merge.

I think the best would be to have both: interactive and non-interactive
merge. This should simply be an option to the merge command.

> - Allow as much automatic merging to be performed as possible without
> requiring human interaction.
>
> - Allow declarative conflict resolution to avoid any human interaction
> (e.g. --resolve-conflict-using=[older|theirs|mine]), supporting some
> degree of conflict resolution from merges (e.g. build automation).
>
> - Maintain compatibility with the diff3 command.
>
> - Allow for resolution more types of conflicts (e.g properties,
> obstructions, etc.).
>
>
> Possible implementation:
> [..]

> Question for IDE developers:
>
> I'm really curious how IDEs handle this situation today. Taking
> TortoiseSVN as an example, I've heard that its TortoiseMerge diff3
> program is great for conflict resolution (though currently lacking an
> edit mode), but not so great for performing merges of a large number
> of changes (e.g. merging changes from trunk into a feature branch),
> especially when the majority of those changes can be applied
> automaticaly with no merge conflicts (and thus don't need typically
> need a merge GUI). Is this an issue for TortoiseSVN/TortoiseMerge
> today, or am I out of date? How about for other IDE developers? How
> do you guys handle this today? ;-)

Thanks for asking.. :)

In earlier versions I changed svn's diff command settings (I think that
was for diff only). That was very awkward to use. Not really usable to
run a graphical diff tool. There were a couple of problems. I can't
remember exactly what the problems were but for that reason I "copied"
part of svns diff code to have proper control over the way the diff
tool is started. I didn't try to run a visual merge this way.

For merge I simply call the merge api like the svn client. Subversion
does all the work and provides the three conflict files for each file
with a conflict. After the complete merge is done I can run
"edit conflict" (from the gui status view) on each conflicted file to
bring up the merge tool with the three conflict files.

-- 
Martin
Subcommander 1.2.1, http://subcommander.tigris.org
a cross platform Win32/Unix/MacOSX subversion gui client & diff/merge tool.
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org