> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: woensdag 4 juli 2012 12:39
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1357214 - in /subversion/trunk/subversion:
> libsvn_wc/conflicts.c libsvn_wc/merge.c libsvn_wc/props.c
> tests/cmdline/merge_tests.py
>
> On Wed, Jul 04, 2012 at 10:25:00AM -0000, rhuijben_at_apache.org wrote:
> > Author: rhuijben
> > Date: Wed Jul 4 10:24:58 2012
> > New Revision: 1357214
> >
> > URL: http://svn.apache.org/viewvc?rev=1357214&view=rev
> > Log:
> > Make it an error to perform a text or property merge into an already
> conflicted
> > node. We can't store two conflicts of the same kind on a node.
> > (And even if we could, it would be very hard to provide a UI to resolve
the
> > conflict).
> >
> > 'svn merge' should probably provide some more user friendly handling for
> this
> > case. Just blocking merging into a somewhere conflicted tree currently
> breaks
> > a lot of tests, while it is certainly *not* best practice to merge into
a
> > conflicted tree.
>
> Can we add an --allow-conflicts switch that overrides this new error,
> like we did for mixed-revisions? That might also make it easier to keep
> the merge tests passing by adding the new flag where appropriate.
That would work for the high-level check, that I couldn't commit because it
would break all kinds of other scenarios.
Low level (where this change was) we should really error on this case and
ask the merge code to resolve the conflict before calling into the merge
code. (Like how it currently handles tree conflicts)
Before this change was applied we just ignored the conflict and wrote a new
conflict right over it. (And we probably did that for several versions).
I do think we should check for conflicts on merging like we do for mixed
revision working copies, but that is outside my current scope of the
conflict handling.
(The status walk in the merge code already does all the hard work, it is
just passing the information to the user. The patch to do that was so small
that I just deleted it, instead of keeping it for future work)
Bert
Received on 2012-07-04 12:54:16 CEST