On 21.04.2016 16:34, Stefan Sperling wrote: > On Thu, Apr 21, 2016 at 02:04:08PM -0000, s...@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
