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

Re: merge very slow

From: Stefan Kng <tortoisesvn_at_gmail.com>
Date: Sun, 15 Jun 2008 15:39:20 +0200

Mark Phippard wrote:

> Merge in 1.5 has to crawl the working copy, and I am pretty sure that
> 1.4 did not. So while I am sure it could be made faster by
> implementing your suggestions, I do not think it can get down to the
> same times as 1.4. At least not on Windows where the working copy
> crawl is so slow.

I don't think it's the working copy crawl in 1.5 that causes the
slowdown. When I step through the code, it often checks whether a
working copy path exists in the repository - and those repo connections
cause the slowdown between 1.4 and 1.5.

> Out of curiosity, what are your timings for svn status on your working
> copy? I'd expect them to be a lot faster than the ones I posted. In
> the tests I did, merge was only 10-12 seconds slower than status. But
> as I pointed out, I was running them in a scenario with high bandwidth
> and low latency.

An 'svn st --ignore-externals' on my TSVN working copy is done in 2-3
seconds. But I'm currently using an svn client built with VS2005 instead
of VS2008. I'm trying to find out whether the merge time is the same as
with a VS2008 build.

> I think it would be interesting to see if VS 2008 has added any time
> to svn status though. My tests with the VC6 build of Subversion
> showed that merge time could be attributed primarily to the status
> crawl.

I think there were some optimizations when fetching the status of a
working copy in 1.5 which would more than compensate any delays caused
by VS008.

Update: the merge is the same when built with VS2005 than with VS2008.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net

Received on 2008-06-15 15:40:00 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.