How about allowing to choose not just at mod_dav_svn v. svnserve granularity, but at the httpd instance / svnserve instance granularity.
Requires 'svnserve --instance-name=foo' (and a corresponding httpd.conf directive) and specifying that 'foo' somewhere in the config file. Stefan Sperling wrote on Tue, Jan 04, 2011 at 20:35:10 +0100: > On Mon, Jan 03, 2011 at 02:35:08PM +0100, Stefan Sperling wrote: > > On Sat, Jan 01, 2011 at 11:58:09PM -0700, Philip Prindeville wrote: > > > I don't care how you do that. As long as it's easily > > > understandable, preferably to both existing users and new ones. > > > > Apart from improving documentation, I cannot think of a way to do this > > which is easily understandable for everyone, sorry. > > Philip (and others), > > Having slept over it, I could come up with a way to do this that is > (as far as I can tell) consistent, backwards compatible, and doesn't > leave behaviour unspecified. The basic trick is to do a repository > format bump. > > However, this goes far beyond adding a new option to svnadmin create > as you originally envisioned, so you may not like this approach. > > I'm not sure if the community would like this. I won't object to > something like this, though I still don't see a lot of added value > coming from it. I won't pursue this further on my own. If you want > this to happen please review the specification below and try to > find holes or errors in it. We could then discuss this further on > the dev@ list to gather feedback, commit it to the Subversion > tree under /trunk/notes/, and file an ENHANCEMENT issue in the issue tracker. > Maybe someone will like the idea and will eventually come up with a patch. > > If you have more ideas for improving Subversion, we're always glad > to hear them. However to really get anywhere, new ideas must carefully > be thought through and specified well. Discussion such as this one, even > if it may seem rigorous and harsh, is an integral part of making that happen. > So I hope you don't feel put off by it. > > Stefan > > ==== > > = Proposal: New servers.conf configuration file in Subversion Repository = > > Subversion repositories can be served over the network by several > server implementations (SI), currently mod_dav_svn and svnserve. > > The goal of this proposal is to provide admins with an easy way to control > which SI will serve a given repository, by editing a configuration file > inside the repository. > > Use cases are: > > A) preventing a repository from being accidentally served by an SI > that has incorrectly been configured to serve the repository > (repositories need to explicitly opt-in to being served by a particular SI) > > B) moving repositories from one SI to another in the case where multiple > repositories are each served by one and only one of several SIs, > without changing the server configuration or repository location > > To realize use case A, admins currently have to: > - understand configuration mechanisms of all SIs in order to > enable or disable repositories per SI > - make sure that repositories that shall be served by a particular > SI are only readable and writable by processes of that SI, and not > by any other processes (each such process could be a misconfigured > Subversion SI) > With this proposal admins will only have to understand how to configure > on SI, as they have to explicitly enable serving by an SI for each repository. > This provides a layer of protection against accidental server > misconfiguration. > > To realize use case B, admins currently have to: > - understand configuration mechanisms of all SIs in order to > enable or disable repositories per SI > - either move repositories around in the server filesystem > or change the SI configuration > With this proposal admins still need to understand how to configure > all SIs, but the instead of moving a repository or changing server > configuration files, it is sufficient to edit a single configuration > file within the repository. > > = Impact on the repository format = > > A format bump (in REPOS/format, not REPOS/db/format) is required. > The new feature shall only be activated for repositories with the new > format number in REPOS/format. > > A new file will be created at REPOS/conf/servers.conf inside the repository. > It contains configuration directives in an ini-style format so that existing > configuration file parsers in the Subversion code base can be used. > The default content of this file is as follows: > > # This file specifies which Subversion server implementations > # may serve this repository. > # > # Uncomment the following lines to enable serving by mod_dav_svn > #[mod_dav_svn] > #enabled = yes > # > # Uncomment the following lines to enable serving by svnserve > #[svnserve] > #enabled = yes > > So, by default, serving for the repository is disabled. > > ra_local (file://) access isn't currently covered by this proposal. > > = Impact on the Subversion Repository API (libsvn_repos) = > > There needs to be an API to query the repository for the configuration > parameters specified in servers.conf. > > = Impact on svnserve and mod_dav_svn = > > If the repository format number is too old, the repository should > always be served, regardless of whether REPOS/conf/servers.conf exists. > > Otherwise, whenever a client attempts to open a new RA session, svnserve and > mod_dav_svn need to query the new libsvn_repos API to decide whether > to serve a repository. > > If serving the repository is not allowed, some action must be taken that > causes the client to exit with an error. For instance, the repository could > be hidden from the client by returning a "path does not exist" error. > > = Impact on svnadmin create = > > When a repository in the new format is created, the file > REPOS/conf/servers.conf must be created with the content given above. > > This means that new repositories will not be served by default. > This must be documented in the release notes. > "svnadmin create" should also print a message telling users about the > necessity to enable serving of the repository: > "If you wish to serve this repository over the network (via mod_dav_svn > or svnserve), remember to edit $REPOS_PATH/conf/servers.conf" > > = Impact on svnadmin upgrade = > > To avoid breaking existing setups on upgrades, REPOS/conf/servers.conf > must be created when upgrading a repository to the new format, > with content that allows serving by every SI: > > # This file specifies which Subversion server implementations > # may serve this repository. > # > # Enabled by svnadmin upgrade: > [mod_dav_svn] > enabled = yes > # > # Enabled by svnadmin upgrade: > [svnserve] > enabled = yes > > "svnadmin create" should also print a message telling users that serving > of the repository has been enabled.
