On Sat, 30 Apr 2005, John Peacock wrote:
> John Peacock wrote:
> >> Also, we should not be assuming that server configuration comes in the
> >> form of a repository config file. Personally, I think all
> >> server-to-client configuration goals can be accomplished by adding new
> >> directory properties.
> >
> >
> > That's the other option I originally discussed in my #3, but it means
> > that each and every directory in the WC must contain a duplicate of the
> > available server config data. We aren't usually talking about a lot of
> > data, but it is a consideration. It's more of a problem with inherited
> > properties (this time assuming that those are associated with directory
> > properties).
>
> Actually, it occurred to me that we could have both distributed directory
> properties _and_ centralized storage. This gets deeper into implementation than
> we should be when discussing design, but if we mark the WC admin files such that
> "this directory has additional properties" and then /store/ the shared
> properties in the .subversion directory, we get the best of both worlds. The
> directories can share the single set of server-mediated config files, and in the
This means that working copies are no longer self-contained. I think that
has been a design goal (but someone could correct me if I'm wrong).
> 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).
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 30 18:16:39 2005