Re: ideas to make svn update faster.

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.

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 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..

-- 
Thomas Zander