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

Re: [TSVN] Re: Re: Severe performance degradation observed

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2004-12-14 10:02:28 CET

At 08:38 14/12/2004 +0000, you wrote:

>SteveKing wrote:
> > Showing WC-roots always _is_ slower than showing a subfolder. You see,
>Agreed, and maybe that's why it is easy to see the speed change in this
>case. But later revisions are much slower than earlier revisions, so
>something has changed. Of course it could be that Russell applied one of
>the patches between these 2 revisions, but I thought that happened
>earlier. I will check in the mail archives.

It could also be that the SVN patches were *lost* between these revisions -
without one of them there's a vast amount of unnecessary recursion through
the WC tree.

Need to check with Russell. Although I could take the latest TSVN source
and run some of my status-fetch profiling stuff against it, I can't be
confident that I'm building against the same SVN code as Russell does.

This is one of the biggest potential problems with the manually applied
patches - something very similar occurred around 1.0.8, which caused that
release to have terrible performance.


Because of the TSVN release policy, people then just have to tolerate the
TSVN regression until there's another SVN release, which can be
months. c.f. Right-click menu, which is currently missing in official
release TSVN and won't be back until SVN makes another release.

I don't support any of the calls for much more frequent 'official
releases', but I do think that where big regression clangers are dropped on
a release, it would be a good idea to do an interim version which fixes them.

... End aside



To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Dec 14 10:03:26 2004

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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