I've been putting off making a config file for svnserve because I have
no idea how to do server configuration under Windows. But today the
light dawned on me: I can just put it in the repository.
Pro: * No portability issue.
* Can have different repositories with different configuration.
Con: * If you have many repositories and want the same configuration
for all of them, it's more of a pain.
* Global options (-r, -T, possible future options for port
number and chroot) remain command-line parameters for now.
(-d, -t, and -X also remain, but those are more "modes of
operation" than "configuration options".)
Here's a more specific proposal:
* Deprecate -u (believe unauthenticated username) and -R
(read-only), and display a warning if they are used. Remove
support for them after a few 0.xx Subversion releases.
* After the repository is selected, serve() looks for a file
"svnserve.conf" in the repository directory. It understands:
[general]
believe-usernames = {true|false} # Default is false
anon-access = {read|write|none} # Default is read
auth-access = {read|write|none} # Default is write
[users] # For CRAM-MD5 auth
username = password
While they still work, -u changes the default for
believe-usernames to true, and -R changes the default for
auth-access to read.
* When a new repository is created, a template svnserve.conf is
dropped in, just like we have sample hooks.
Question: Should the default for anon-access be none, instead of read?
There's something to be said for the theory that all access should be
granted explicitly, never implicitly. But on the other hand, we are
targeting open-source projects here. (Also, making the default none
would present an immediate transition issue for svnserve users.)
Question: When I (hopefully) add path-based auth support, do people
think I should just fold it into this file, or should it be a separate
file so that it can have exactly the same format as the mod_authz_svn
control file?
General comments are also welcome. I will get started on implementing
this, but
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 28 21:05:23 2003