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

Unexpected Merge Behavior

From: Daniel Becroft <Daniel.Becroft_at_supercorp.com.au>
Date: Thu, 4 Sep 2008 11:58:14 +1000

Hi all,
 
I have only recently started playing around with SVN's merge
capabilities, and have found something strange.
 
I have checked-out a fresh, unmodified copy of a branch in the
repository.
 
The structure is similar to this:
 
    \alpha
        \A
            \B
                \C.txt
    \beta
        ...
    \gamma
        ...
 
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.
 
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.
 
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?
 
Cheers,
Daniel B.
Received on 2008-09-04 03:57:41 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.