Before you wander too far down this path, there is one hard design
constraint:
* Configuration from the repository cannot specify unconstrained
behavior on the client. It cannot, for instance, tell the client what
diff command to run, since then it could run arbitrary commands.
As a consequence, repository-based configuration cannot be treated as a
convenient substitute for all client configuration. Because of that, it
makes the most sense to limit repository-based configuration to things
which talk about the repository's content. Custom keywords definitely
fit in that category.
We already have a mechanism for the repository to configure the client :
properties. We use them to configure newline expansion, keyword
expansion, the ignored file list, and the executable bit, on a per-file
or per-directory basis. The down-side of properties right now is that
you can't automatically apply them to new files or directories. The
up-side is that you can make them different for different parts of the
repository; perhaps someone might want your custom keyword functionality
only to apply to a specific file or directory.
I think it may make more sense to flesh out properties than it would to
create a new framework for configuration. Some ideas:
* Move (well, copy, given that we're at ~1.0 right now) the auto-props
functionality from the config file to a directory property. Consider
adding a syntax to auto-props which specifies that the auto-props
property itself gets copied to new directories.
* Create an svn:inherit property (or a pair of properties) which
simply specifies which properties are inherited by new files or
directories. That could take the place of the special auto-props syntax
proposed above.
> 4) Overrideable by the local .subversion/config or...
Why? Give a specific example of something which genuinely belongs in
per-repository configuration for which there is a legitimate need for a
client-level override.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 3 18:09:34 2004