subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject 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
Date Thu, 21 Apr 2016 16:54:03 GMT
On 21 April 2016 at 19:44, Stefan Sperling <stsp@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@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

Mime
View raw message