subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <>
Subject Re: Reintegrate-like merges and diff_ignore_ancestry
Date Tue, 05 Feb 2013 11:56:19 GMT
On Fri, Feb 1, 2013 at 3:57 PM, Ivan Zhakov <> wrote:
> On Fri, Feb 1, 2013 at 1:49 AM, Ivan Zhakov <> wrote:
>> On Wed, Jan 23, 2013 at 9:39 PM, Paul Burba <> wrote:
>>> On Wed, Jan 23, 2013 at 9:51 AM, Julian Foad <>
>>>> Ivan Zhakov wrote:
>>>>> I was testing recent changes in ra_serf update editor and noticed that
>>>>> reintegrate-like merges for long living branches are extremely slow.
>>>>> Client requests server for diff between branches with respect to
>>>>> ancestry and servers reports no-op txdelta for every file that was
>>>>> changed in original branch. Then for every such file client retrieves
>>>>> text and properties.
>>>>> For example try to reintegrate ev2-export branch back to trunk.
>> [...]
>> Hi Bert and Paul!
>> On Wed, Jan 23, 2013 at 6:51 PM, Bert Huijben <> wrote:
>>> Is there a way the diff code can see that it receives a no-op txdelta?
>>> In that case it can just skip retrieving the file as it won't be able to produce
a difference anyway.
>> It would be really hard to implement on client, because no-op txdelta
>> transmitted as full txdelta with instructions to copy all source data.
>> But we can detect such no-op txdelta on server side. See my plan bellow.
>>>> Thanks Ivan, that's very interesting.  I'll take a look, since I have just
been working on that code.
>>>> I exposed this as a separate option because the
>>> two meanings of the previous 'ignore_ancestry' option were conflated, but I don't
deeply understand what happens when this option is specified.  I know what it's
>>> supposed to mean at a basic level: "diff a pair of unrelated nodes as if they
are related".  What I don't know is how well it's implemented and whether it's really useful
when merging.
>>>>> What is the purpose of diff_ignore_ancestry for merges? Can we default
>>>>> it to FALSE?
>>>> I assume one of the purposes is if your work flow has been such
>>> that a file is sometimes replaced (without copy-from)
>>> Any replacement is a problem, regardless of copy-from.  For example:
>> [...]
>>>>, and sometimes a new file added on one branch has been added on  the
>>> other branch by a simple add (without copy-from).  In that sort of work flow,
>>> the 'diff_ignore_ancestry' would cause Subversion to do diffs between
>>> different versions of a file, and that might well help in merging the changes.
>>> Without the 'diff_ignore_ancestry' option, Subversion would treat the file as
>>> 'replaced', and so you'd be likely to get a tree conflict when you try to merge
>> Thanks for demonstrating use-case. That what I was looking for. We
>> cannot change to ignore_ancestry  = TRUE by default, but I'm going to
>> try the following:
>> 1. Add test case for replacement merge that you demonstrated (it would
>> be useful anyway)
> Test added in r1441400.
>> 2. Modify delta reporter on server side to do not send deltas if files
>> have the same content, regardless ancestry (see
>> subversion/libsvn_repos/reporter.c:696 delta_files()) Patch attached.
> The new test for merge replacements also passes with my patch. So I'm
> going to cleanup it and commit after further testing.
Committed r1442555.

Ivan Zhakov

View raw message