Thomas Zander wrote:
> 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. So in practice only one dir up
> will be read the first time; and a second time only the current one.
>
>
>> [...] Do you agree? [...]
>>Do you agree? [...]
>>Do you agree?
>
> 3 x Yes
>
>
>>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. In fact; the only usecase where this will have an effect is
> if you usually do a global update (your whole project) and then only update
> one nested subdir. Then _one time_ will that do some extra reads.
>
> Which part of my answer don't you understand? I pasted it 3 times and you
> still have not responed to it.
I must admid, I don't understand it, too.
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!
Performance of wc management definitely is a problem in subversion.
But I also understand that the problem is not easy to solve.
The problem is easy to solve for other version control systems
lacking important features due to the patch based design
(e.g. lacking GUIs like Tortoise, or lacking mixed revisions,
or lacking efficient access to per-file infos, or lacking
automatic detection of local modifications etc. etc. etc.).
But the problem is not easy to solve if you want to continue
supporting such features.
And svn is so popular because it offers these features.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 17:21:48 2005