David Glasser wrote:
> On 3/26/07, Daniel Rall <firstname.lastname@example.org> wrote:
>> While I haven't reviewed this patch thoroughly, from the description
>> I'm not in favor of it. Rather than having the global configuration
>> file override any values specified for per-repository configuration,
>> shouldn't this work the other way around, as it does for our client
>> library configuration files? Per-repository configuration should be
>> overlayed on top of a global configuration file.
> My thoughts were similar. From Blair's comments in STATUS, it seems
> like a major incentive here is to not require parsing config on every
> svnserve access. I'm not sure if this optimization saves much, but
> perhaps the best way to handle this is to make a global config file
> which is overridden by per-repo files, and a new global-only
> configuration option "ignore-repository-configuration"?
<aside>The incentive is to make it easier to manage thousands of
repositories, the performance is a bonus.</aside>
It's easy to have the per-repository svnserve.conf and the passwd
information be merged on top of the global svnserve.conf and passwd
It's not clear to me if we want to support merging of passwd and authz
date though. Also, we have no public API for merging authz data,
although under the hood, authz is a svn_config_t.
Do we want to leave it to the administrator to ensure they're not doing
something stupid like opening a hole in one repository when they modify
the global authz file?
Also, given this is security related, maybe we want to provide the
option of merging or replacing the global data? The setting could be
named "per-repository-configuration" and have the following settings:
Ignore any per-repository config's
Replace any global svnserve.conf, passwd and authz data with the
Merge in any svnserve.conf, passwd and authz data
It sounds like the safest is ignore and replace, with a merge being
something maybe the administrator should explicitly use.
I can add a check in the code for --config-file that checks for a
"per-repository-configuration" option, once we work out the design here.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Mar 27 03:01:49 2007