On Wed, 22 Nov 2006, Martin Hauner wrote:
...
> Daniel Rall <dlr@collab.net> wrote:
...
> > 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.
Yup!
> I would expect that the (non interactive) merge procedure will not
> change.
Some tools (e.g. ClearCase) allow you to specify which version to use
(old/working/new) to automatically perform non-interactive merging.
Apparently this is popular with SCM build automation.
The callback I'm suggesting would allow this type of thing to be
implemented (meaning one could theoretically change the
non-interactive merge process).
> If merge tracking allows multiple conflicts with differnt merge
> ranges svn should stop after the first conflict and write the four
> files like now.
This was my initial reaction, too. However, that's a rather major
departure from the current semantics of 'svn merge' (which now always
attempts to merge all requested revisions), and not particularly user
friendly for the merge to simply stop part way through...
> ... 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.
I think we actually have to stop applying any more revision ranges
after a conflict occurs (not just to that file), since there may be
directories or obstructions involved which subsequent merges depend
on.
Your idea of storing some state about the requested-but-unmerged
revision ranges and supplying some mechanism to restart the merge is
interesting! ('svn resolved' wouldn't be the correct place, though.)
We could output a message indicating that only a partial merge
occurred, and then allow some sub-command (e.g. 'svn merge --restart')
to continue the merge after conflicts had been resolved in the
traditional manner.
If we go this direction, we'd punt on the merge resolution callback
idea. Which do y'all think is more user friendly?
> > 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.
There's already a global --non-interactive flag on the 'svn'
command-line client. We'd pass the equivalent of this information
along to allow a merge resolution callback to DTRT.
> > - 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.).
...
> > 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.. :)
You're welcome! :)
> 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.
http://svn.collab.net/repos/svn/trunk/CHANGES shows that there's been
numerous problems with the custom diff3 command over the years, and
invoking a GUI diff3 for every merge doesn't sound particularly
enticing, either.
> 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.
Gotcha, thanks for the description.
It sounds like everyone is clear now on how the merge-tracking
branch's multi-revision range merge implementation will affect
merging and conflict resolution.
- application/pgp-signature attachment: stored
Received on Thu Nov 30 02:30:30 2006