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

Re: ideas to make svn update faster.

From: Folker Schamel <schamel23_at_spinor.com>
Date: 2005-05-08 18:15:24 CEST

Thomas Zander wrote:
> On Sunday 08 May 2005 17:18, Folker Schamel wrote:
>>Thomas Zander wrote:
>>>I'll paste it here:
>>>you are almost sure to have different
>>>versions in the individual dirs as is; this won't change if only
>>>changes to the parent are recorded, like I proposed. So in practice
>>>only one dir up will be read the first time; and a second time only the
>>>current one.
> ..
>>I do global updates quite regulary (-> rev is the same for all dirs and
>>files). But also use Tortoise all the time.
>>And Tortoise performance already is a serious problem,
>>because it hooks windows itself (the explorer).
>>So it seems that your proposal would make subversion
>>multiple times slower for an typical use-case.
>>Acceptable? Definitely not!
> Making things multiple times slower surely is unacceptable; I fully agree.
> But please tell me how you come to the conclusion that this would be the
> case?
> Just reading an xml file is something that already happens for each and
> every directory you have managed; if you do an update from the root level
> its going to be faster, if you do an update lower it could cause a couple
> of extra local filesystem reads. That does not translate to multiple times
> slower at all.

I'm not talking about the performance of updates. I'm talking about Tortoise,
as already explained in my previous email.
And Tortoise queries the wc status non-recusively, which then would
have to go up to root all the time instead of a single file read,
as already explained by Philip.
Which translates into multiple times slower.

You also may look into the archives of this list and the tsvn
list about the dozen discussions about tsvn performance.

> So stop worrying :-)
>>Performance of wc management definitely is a problem in subversion.
>>But I also understand that the problem is not easy to solve.
> The problem I am running into here is that nobody seems to try to understand
> the other and just repeats old points while ignoring explanations.

My impression is that the svn guys understand you very well.
But you seem to have only limited view of svn (and its tool family),
and how it is used, and as consequence you seem to not really
understand the issues.

For example, do you use Tortoise?
Do you know how it works?

>>My impression is that the svn team knows very well the
>>performance problems.
>>And it also knows very well possible solutions because
>>it understands both subversion and its implementation
>>(see the wc performance paper already quoted some mails ago.)
>>Providing "good ideas" without the latter is not really helpful.
> I'm not going to ask them to explain the whole thing in detail to me, that
> would be impractical indeed. What I do expect is that if someone tries to
> pose a 'good idea' is that people try to understand it and not simply say
> its going to fail followed by an argument thats incredibly easy to debunk.
> In short; I expect people to talk about technical implementations; since it
> is my understanding that that is what this list is for.
> But I'm seriously starting to doubt that is what this list is being used
> for..

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 18:16:19 2005

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.