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

On 21 April 2016 at 19:44, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, Apr 21, 2016 at 07:37:50PM +0300, Ivan Zhakov wrote:
>> On 21 April 2016 at 17:34, Stefan Sperling <stsp_at_apache.org> wrote:
>> > Implementation aside, I do think the option to merge the two directories
>> > makes sense, even if they are ancestrally unrelated.
>> May there are some implementation problems, but I think merging two
>> directories makes sense: it's real world case during some refactoring.
>
> Yes, it makes sense, as I already stated (did you read "don't" where
> I wrote "do"?)
>
Oops, sorry. I misread your sentence.

> But the implementation should work.
> Any idea how can we can avoid the problems I have described?
I don't understand all details, but I don't think that using merging
code in resolver would be sufficient in long term. But we can use for
initial implementation though. Also as far I remember sub-tree
mergeinfo makes further operations significantly slower. Can we just
leave svn:mergeinfo unchanged for subtree?

-- 
Ivan Zhakov