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 20:36:08 CET