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

Re: svn commit: r1740320 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/conflicts.c svn/conflict-callbacks.c tests/libsvn_client/conflicts-test.c

From: Branko ─îibej <brane_at_apache.org>
Date: Thu, 21 Apr 2016 18:55:13 +0200

On 21.04.2016 16:34, Stefan Sperling wrote:
> On Thu, Apr 21, 2016 at 02:04:08PM -0000, stsp_at_apache.org wrote:
>> Author: stsp
>> Date: Thu Apr 21 14:04:08 2016
>> New Revision: 1740320
>> URL: http://svn.apache.org/viewvc?rev=1740320&view=rev
>> Log:
>> Add a conflict resolution option for dir/dir "incoming add vs local
>> obstruction upon merge". This option merges the two directories.
>> Again, the implementation is not atomic, yet.
>> And it doesn't always work as expected.
>> Add two XFAIL regression tests which illustrate known problems.
> I'll need some help here to decide how to proceed.
> Briefly, the problems I'm running into are:
> - It is not possible to merge an "only-adds" delta from rN-1 to rN for
> a path created in rN. Essentially, this is the same issue as we had
> for 'svn diff -cN' for a node created in rN, which was fixed at some point.
> So this is a case where svn diff -cN works, but svn merge -cN doesn't.
> I now need svn merge -cN to work in this case (see the 1st of 3 tests
> added in this commit).

I suppose this just needs to be fixed in the merge code.

> - I'm not sure to what extent the resolver should be responsible for
> mergeinfo. Should it assume that existing mergeinfo in a working copy
> remains valid when further merges are performed to resolve a tree
> conflict? I guess not. In the case I'm looking at, the merge only
> produces a delta if run with --no-ancestry (why?) which disables
> mergeinfo recording. It is possible to construct cases where the lack
> of additional mergeinfo recording seems wrong (see the 3rd of 3 tests
> added in this commit).
> Does anyone have suggestions about these problems?
> Should the resolver be using the standard merge code at all in this case?
> Perhaps that's the wrong approach?

If we have a resolver that can merge directories, then yes, I'm pretty
sure it should be using the standard merge code and definitely not
reinventing the wheel.

As for mergeinfo: conflict resolution isn't really merging, just as 'svn
update' isn't really merging even though there's a lot of that going on
under the hood. The only cases where the merge could theoretically
produce mergeinfo is for conflicts that involve directory move/rename
... which we currently do not track in mergeinfo.

-- Brane
Received on 2016-04-21 18:55:18 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.