On Wed, Jan 23, 2013 at 9:51 AM, Julian Foad <julianf...@btopenworld.com> wrote:
> 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)

Any replacement is a problem, regardless of copy-from.  For example:

### Starting with a vanilla Greek tree,
### make a branch:

>svn copy A branch
A         branch

>svn ci -m "make branch"
Adding         branch

Committed revision 2.

### Now replace two files on the branch,
### one with history, one without:

>svn del branch\B\lambda
D         branch\B\lambda

>svn move branch\D\gamma branch\B\lambda
A         branch\B\lambda
D         branch\D\gamma

>svn del branch\mu
D         branch\mu

>echo replacement without history > branch\mu

>svn add branch\mu
A         branch\mu

>svn st
R  +    branch\B\lambda
        > moved from branch\D\gamma
D       branch\D\gamma
        > moved to branch\B\lambda
R       branch\mu

>svn ci -m "Replace some files on the branch"
Replacing      branch\B\lambda
Deleting       branch\D\gamma
Replacing      branch\mu
Transmitting file data .
Committed revision 3.

>svn up -q

### Sync merge from 'A' to 'branch':

>svn merge ^^/A branch
--- Recording mergeinfo for merge of r2 through r3 into 'branch':
 U   branch

>svn ci -m "Synch the branch with its parent"
Sending        branch

Committed revision 4.

### Now do a "reintegrate" style auto merge
### without Ivan's patch.  The replacements
### are merged as expected:

>svn merge ^^/branch A
--- Merging differences between repository URLs into 'A':
R    A\B\lambda
R    A\mu
D    A\D\gamma
--- Recording mergeinfo for merge between repository URLs into 'A':
 U   A

>svn st
 M      A
R  +    A\B\lambda
D       A\D\gamma
R  +    A\mu

### Now try the same merge with Ivan's patch.
### History is lost as the merge treats the replacements
### as simple modifications:

>svn revert -Rq .

>svn merge ^^/branch A
--- Merging differences between repository URLs into 'A':
U    A\B\lambda
U    A\mu
D    A\D\gamma
--- Recording mergeinfo for merge between repository URLs into 'A':
 U   A

>svn st
 M      A
M       A\B\lambda
D       A\D\gamma
M       A\mu


>, 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



-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Reply via email to