Re: [POST 1.0 task] Custom Keywords - Issue 890

Ben Collins-Sussman wrote:

> This is the big design problem: the feature you want, along with other
> post-1.0 features, need a general mechanism by which clients can fetch a
> run-time config file from the *repository*. This means possibly adding
> a new RA method.

I was thinking about this in the shower this morning. I don't see much
discussion in the Issues listing about site-specific configuration files, just
this one:

        http://subversion.tigris.org/issues/show_bug.cgi?id=1054

which is short on details. Similarly, I am unable to locate much discussion on
the dev list archive (though the lack a good search tools is probably to blame).
Consequently, the following is completely uninformed by what others may have
already suggested. ;~)

What I was thinking about was what the criteria for a server-hosted config file
would be:

1) Normally visible only to the client software (i.e. not directly to the user)
using any RA layer;

2) Versioned (so that it could be updated by the administrator and still be
consistent for historical checkouts);

3) Exportable (for backup purposes);

4) Overrideable by the local .subversion/config or /etc/subversion/config files
(at least to some extent).

Items 1-3 strongly suggest that the configuration file should be an object in
the filesystem, which would not be visible to the user. This would also allow
an inherited model, so that the repository-wide settings would be at the root of
the repository, the project-wide settings could be at the root of a project, and
so on.

Thinking about implementation details, this could either be a normally hidden
file in the repository (.$UUID.config maybe), or a versioned property of a
directory (which I like more and more as I think on it). #4 is strictly a
client implementation issue, in that the hierarchy of config files would be read
in turn and the parameters merged or overridden.

When checking out a subtree, the server process could walk the tree and compile
the inherited configuration, which could then be associated with the root of the
checked out portion. So it may be necessary to have a "config" (which would be
an editable object in the repository) and a "vconfig" (which would be the config
settings in force for any given directory, based on inheritance, and readonly in
the WC).

Where it starts getting messy is when a given directory is a copy of some other
directory in the repository. Does the inheritance follow the actual source of
the directory/files or does the inheritance follow from the current hierarchy of
directories. And what about svn:externals? The experience of designing
svn:externals is probably worth looking at, since in many ways this maps closely
with the idea of a repository resident config file.

Thoughts?

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org