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

Re: Unexpected Merge Behavior

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Thu, 4 Sep 2008 00:05:21 -0500

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

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.