[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-05-08 13:27:58 CEST

Thomas Zander <zander@kde.org> writes:

> On Sunday 08 May 2005 01:12, Philip Martin wrote:
>> Thomas Zander <zander@kde.org> writes:
>> > On Saturday 07 May 2005 22:36, Philip Martin wrote:
>> >> Thomas Zander <zander@kde.org> writes:
>> >> > Or maybe I'm not following your 'non-recursive status' point above;
>> >> > in that case please explain what you mean by that.
>> >>
>> >> As I understand it you propose to avoid storing the revision in a
>> >> directory's entry file if the revision matches that of the parent. To
>> >> get the revision TSVN is going to have to read all the entries files
>> >> up to the root rather than just the the one for the directory in
>> >> question.

The paragraph above...

>> > If it doesn't update recursively; then 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.
>> >
>> > Right?
>> You seem to be referring to update but I'm worried about status. If
>> your idea to make update faster causes status to be slower then it's
>> probably a non-starter.
> I agree. Now; why would they be slower? I don't see _how_ they could be
> slower, actually.

...is my answer to your question.

> I have no problem with you questioning a new approach; but please don't just
> hit me with arguments that have absolutely no backing in theory. Makes
> conversing a lot easier here...


Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 13:28:45 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.