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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-18 16:25:24 CET

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

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.