[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reintegrate-like merges and diff_ignore_ancestry

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 23 Jan 2013 14:51:49 +0000 (GMT)

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.

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), 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 it.

Another case that demonstrates the option better (but not in an automatic merge) would be if you have two tree snapshots (vendor drops of product version 1.1 and 1.2, say) and you want to merge the difference between them into your working copy.

Can we default it to ... I think you mean TRUE, in an automatic merge?  Perhaps.  But let me take a look at the code to see if this is buggy behaviour, first.  Also I'll try to think whether it makes sense to default to TRUE and whether we'd then want a user interface override like the existing 'svn diff --notice-ancestry' option.

> I've made simple patch that changes unconditional diff_ignore_ancestry
> = FALSE to TRUE in merge_cousins_and_supplement_mergeinfo() call and
> everything seems to be working and ALL tests are passing.

You mean in the call to merge_cousins_and_supplement_mergeinfo() in do_automatic_merge_locked(), I assume.

- Julian
Received on 2013-01-23 15:52:26 CET

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.