[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: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 21 Apr 2016 19:54:03 +0300

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
Received on 2016-04-21 18:54:33 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.