[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pre-Design Discussion of Server->client configuration

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-04-30 23:32:38 CEST

Peter N. Lundblad wrote:
> 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 think we can reasonably assume that the server-side config data will be slow
changing (compared to any reasonable project churn), and in many cases will be
basically static once the WC is checked out. In the case mentioned, a shared
WC, each user accessing the WC would need to contact the server *once* if they
didn't have the shared data. And again each time the server config data
changed. However the normal condition would be that the WC would have a
complete set of server config files, so client-side only operations (like
revert) will continue to be client-side only.

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

That's really an implementation detail, as to how to handle inherited properties
in the tree. If we want to allow multiple sets of server-side config files to
reside in the tree, having a central storage scheme doesn't prevent it (just
store the config in a hash based on directory location in the tree).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 30 23:28:40 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.