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

Unexpected Merge Behaviour

From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
Date: Mon, 8 Sep 2008 09:05:23 +1000

Hi all,
Apologies for posting on the developer list. I have posted this on the
users@ originally, but did not get any explanation. I thought I would go
to the 'source' (no pun intended), to try and get an explanation.
I have only recently started playing around with SVN's merge
capabilities, and have found something strange (SVN 1.5.2 on Windows
I have checked-out a fresh, unmodified copy of a branch in the
The structure is similar to this:
I am attempting to cherry-pick a single revision from trunk and apply it
to said working copy. The revision (r1234) only modifies a single file
(C.txt above), but when I run the following command:
    svn merge -c 1234 svn://localhost/repo/trunk .
the svn process appears to be reading EVERY file in the working copy,
including those located under the \beta and \gamma directories. As a
result, the merge takes approximately 3 minutes to complete. (I used
sysinternal's FileMonitor utility to determine this). When the working
copy contains upwards of 12,000 files, this can extremely slow.
This performance does not sound so bad, but when using the 'multiple
revisions' option for the -C command, like so:
    svn merge -C 1234,1236,1239,1255 svn://localhost/repo/trunk .
it takes approximate 3 minutes PER REVISION - it seems to do a loop
through the revisions and do the same thing for each.
However, I have found that if I structure the merge command such that
the merge is being done on the subdirectory, then the problem is
minimized (all files under alpha/A/B are read, but not /beta or /gamma).
    svn merge -c 1234 svn://localhost/repo/trunk/alpha/A/B ./alpha/A/B
Using either version of the merge command, the only files/directories
that are modified are the parent directory, and C.txt.
The only explanation I got from users@ was that this might be the
'elliding' functionality.
Is this expected behavior for svn merge? Why is it reading completely
unrelated files when attempting a merge, rather than looking at the
changes being applied first? Is this the 'elliding' feature, and if so,
why is it doing this?
Daniel B.
Received on 2008-09-08 01:04:53 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.