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
Received on Tue Jan 18 16:27:04 2005