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

Re: Conflict handling on merge-range application

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-07-14 02:33:28 CEST

On Wed, 12 Jul 2006, Daniel Berlin wrote:

> Garrett Rooney wrote:
> > On 7/12/06, Daniel Berlin <dberlin@dberlin.org> wrote:
...
> >> The conflicts in this merge may have come from any single revision
> >> change, but the end result will still represent them all.
> >>
> >> Why do you think we should do something different just because we've
> >> elided a revision in the middle?
> >
> > Well, mainly beacuse we don't currently handle merging into a
> > conflicted file sanely. As dlr already mentioned, overlapping
> > conflict markers don't work, etc. If you want to make that work then
> > fine, but honestly I still think the idea of merging into an already
> > conflicted file is kind of strange.
>
> I agree that if your conflicts overlap, it might be strange.
>
> Otherwise, i don't think so.
>
> I'm willing to start somewhere, and say we abort merges if we hit
> overlapping conflicts.

Okay. For starters, we could define "overlapping conflicts" as "any
second conflict to a WC item" (probably determined via the equivalent
of 'merge --dry-run' for items which are already in conflict). Later,
we should drill into the diff/merge code and see if we can narrow this
down to true conflict overlaps. (I'm assuming this means an API
change, which is my primary reason on holding off on restricting this
to true conflict overlaps for the time being.)

> However, I do believe we are going to get significant user pushback
> on this.

I tend to agree.

To improve this user experience, how about providing a callback that
an interactive merge tool written against Subversion's API could use
to do conflict resolution *during* the merge. This would help a
third-party merge tool like Araxis Merge, but a more tightly coupled
tool (TortoiseMerge?) could take advantage of this.

A successful conflict resolution during the merge would turn the 'C'
into an 'M', and allow merging of revision ranges to continue. An
unsuccessful conflict resolution would abort the merge after
application of the remaining changes from the current revision range
to the user's WC.

  • application/pgp-signature attachment: stored
Received on Fri Jul 14 02:34:17 2006

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