Re: ideas to make svn update faster.

Thomas Zander <zander@kde.org> writes:

> On Sunday 08 May 2005 14:21, Philip Martin wrote:
>> Thomas Zander <zander@kde.org> writes:
>> > On Sunday 08 May 2005 13:27, Philip Martin wrote:
>> >> Thomas Zander <zander@kde.org> writes:
>> >> > On Sunday 08 May 2005 01:12, Philip Martin wrote:
>> >>
>> >> The paragraph above...
>> >
>> > ..
>> >
>> >> ...is my answer to your question.
>> >
>> > I posted an answer to prove you wrong twice already; please respond why
>> > you don't think that fixes it. With an example if that will make it
>> > clearer.
>>
>> Either I didn't see it, or I didn't understand it.
>
>
> 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.

That makes no sense to me. Your proposal concerns updates that affect
the whole working copy (your "global update") and cause the revision
number to be stored in the root entries file only.

>  So in practice only one dir up
> will be read the first time;

That makes no sense to me. The root might be several levels up,
status will have to read all the intervening entries files.

> and a second time only the current one.

That makes no sense to me, what changes between the first and the
second time I run status?

>> [...] Do you agree? [...]
>> Do you agree? [...]
>> Do you agree?
> 3 x Yes

It looks like you agree that status will be slower after a "global
update".

>> While your idea may make update faster, it will make other operations
>> slower.
> No; read my answer on how in practice this will not happen in the usecase
> you proposed.

My usecase is a user running status on bits of a single revision
working copy.

> In fact; the only usecase where this will have an effect is
> if you usually do a global update (your whole project)

That's my usecase.

> and then only update one nested subdir.

That makes no sense to me. I'm concerned about single revision
working copies.

> Then _one time_ will that do some extra reads.

That makes no sense to me. What does "one time" mean? Every time
status runs it will be slower.

> Which part of my answer don't you understand? I pasted it 3 times and you
> still have not responed to it.

I responded as well as I could, but your argument makes no sense to
me. You want to make "global update" faster. You agree that your
proposal will make status slower after such an update. Then you argue
that the slowdown doesn't matter for reasons I don't understand. As
far as I can tell you give are two reasons why the slowdown doesn't
matter: a) it doesn't occur "in practice", and b) it only happens "the
first time".

The "in practice" bit doesn't make sense. If you want to optimise
"global update" because it's important to you, you cannot then go on
and argue that it doesn't occur "in practice". That's just silly.
Also I think it does occur "in practice".

The "first time" bit doesn't make sense either. Your proposal relies
on the revision number only being stored in the root, so that most of
the entries files don't have to be changed. Running status isn't
going to change those entries files, and if it did it would defeat
your optimisation, so every time status runs it will be affected.

I'm trying to take your arguments seriously, but it's getting harder.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org