On Sun, Sep 7, 2008 at 7:05 PM, Daniel Becroft
<Daniel.Becroft_at_supercorp.com.au> wrote:
> 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.
You should really just re-raise the issue on users@ then.
> =============================================
>
> I have only recently started playing around with SVN's merge capabilities,
> and have found something strange (SVN 1.5.2 on Windows XP).
>
> 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. (I used sysinternal's
> FileMonitor utility to determine this). When the working copy contains
> upwards of 12,000 files, this can extremely slow.
This is the normal behavior. It has to scan the mergeinfo of the WC
before the merge to communicate to the server what you have so that
the server knows what deltas to send.
> 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.
Yes, that is exactly how it works. The syntax is convenience, the
behavior is no different than executing three commands.
> 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.
As you say, the behavior is the same, but by focusing the tree you are
just narrowing down the part it needs to look at. It is worth
pointing out though that this will create the mergeinfo at that part
of the tree, which is exactly the sort of situation the original scan
has to look for. I am not saying that you should not use this as your
technique. But the point is that if you did it this way one time, and
another time you used the root URL you would still expect the merge to
work. So it has to determine what is in your working copy and what
revisions have been merged to the various subtrees.
The good news is that this is an area that could see huge benefits
from a working copy rewrite. There is no need to scan the tree, just
to get all the mergeinfo for the tree. If this could all be retrieved
from a single central location the overhead of doing this would be
fairly minimal. It just so happens that in the current working copy
design it is very non-performant.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-09 04:31:46 CEST