Repository-based client configuration schemes [was: tsvn:logwidth in svn repository]

[Julian Foad <ju...@btopenworld.com>]

Re-posting with a better Subject line.

- Julian


Rob Oxspring wrote:

Greg Hudson wrote:
 > Actually, I do have a mild negative sentiment towards a "repository
 > configuration" mehacnism, because almost any kind of "repository
 > configuration" could, conceivably, want to vary within the repository.
 > For instance, the Apache repository might very well have different
 > projects which prefer different log widths.
 >
 > So, repository configuration seems like a good way to introduce
 > configuration values with the wrong scope.  I would rather see these
 > things implemented as directory properties (as tsvn:logwidth already
 > is), and make it easier to apply directory properties to whole
 > subtrees.

This makes a lot of sense so adapting from Steve's and Jani's thoughts then, 
how about adding a property that points to the configuration area for the 
directory you are working on:

When setting up the project set the svn:configdir property of the project's 
directory to point at the project's configuration directory:
   svn propset svn:configdir ./config file:///path/to/repo/path/to/project/

When a checking out or updating a part of the project the server checks that 
each directory has the server checks that svn:configdir has been set or 
calculates a virtual property based on the parent directory's svn:configdir:
   svn co file:///path/to/repo/path/to/project/component/
   A blah.c
   Checked out revision 22
   Checking out configuration file:///path/to/repo/path/to/project/config
   Checked out revision 22
The configuration gets checked out into:
   ~/.subversion/defaults/<UUID>/path/to/project/config

When committing files, the svn:configdir would be looked up from the 
committables(*) and resolved to the relevent ~/.subversion subdir.  This 
directory would be used as the default configuration for the rest of the operation.

This scheme is pretty flexible and allows per-project repository-backed, 
configuration defaults.  The scheme lifts Steve's requirement that the config 
directrory have specific name which I believe is closer to the subversion 
ethos, but takes the essence of Jani's and Steve's ideas and adapts them to a 
project level rather than repository level.  If the value of svn:configdir was 
allowed to be any url then the scheme would even support having multiple 
'project' repositories sharing a single 'configuration' repository, a feature 
which might well be useful to some.

Sorry for the drive by - one of these days I'll brush off my C skills and have 
a play with the code properly but for now ideas are the best I can do.

Rob

* Obviously a big problem with any project level configuration mechanism is 
that a commit could cover multiple projects with might point to different 
config dirs.  I suspect that the correct solution here would be to choose the 
deepest common directory and grab the config from there but I haven't thought 
through the implications of this yet.

 > I'm not sure if property inheritance is the right mechanism
 > (because it creates so many corner cases); perhaps the poor man's
 > approach of auto-props is sufficient.
 >
 > Of course, auto-props is also a feature we implemented in the wrong
 > scope.  I would like to see auto-props redone as a directory property.


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