On Sep 3, 2008, at 8:58 PM, Daniel Becroft wrote:
> 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?
Are you using Subversion >= 1.5? If so, maybe this is the mergeinfo
eliding feature at work.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-04 07:05:50 CEST