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.
Received on 2011-01-04 21:11:54 CET