On 4/30/05, Peter N. Lundblad <peter@famlundblad.se> wrote:
> On Sat, 30 Apr 2005, John Peacock wrote:
[...]
> > shared WC case, the client code can "know" that it needs to contact the server
> > to get the server config files when they are not already present in .subversion,
> > yet are flagged in the WC.
> >
> Depending on what we use server configs for, that might not be desirable.
> It might make operations that today are client-side only to require server
> connectivity.
>
> I am not sure central config storage is worth it. A few kilobytes for a
> directory shouldn't be a problem. And it allows us to have finer
> granularity than a repository (say you have different project in the same
> repository).
Hmmm... I think that a "few kilobytes" is not really is direct issue.
However, those "few kilobytes" do multiply up in more ways than one.
First there is the whole directory thing - how many different directories
are in a repository? A number of projects I work with have 5,000+
directories/subdirectories within the repository. A few kilobytes
times 5,000 is starting to add up.
But disk space is "cheap" however disk I/O time is not. Here is
where having files that really are all shared being stored all over
the place starts to make things much slower in multiple ways.
1) You need to read each file - that is at least 3 operations:
open/read/close and most likely more.
2) The OS will need to keep track of more inodes and will try
to cache more filesystem or disk blocks. This puts more preasure
on the cache and thus pushes out data from the cache that is
potentially more useful (assuming that a shared area would work
better)
3) More chance for strange edge cases.
Now, the benefit of having configuration settings being
more fine-grained may be worth the costs. But lets not forget
that it is more than just a "few kilobytes" but that there are
other overheads.
--
Michael Sinz Technology and Engineering Director/Consultant
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 30 21:02:52 2005