On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling <stsp@elego.de> wrote:
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.



= 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.

What's the impact of using svnserve with a --config-file argument?
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
 #enabled = yes
 # Uncomment the following lines to enable serving by svnserve
 #enabled = yes

So, by default, serving for the repository is disabled.

Shouldn't the current behaviour of 'svnadmin create' be maintained? At the moment, a user can just do:

svnadmin create .\repository
svnserve -r .

and a repository is created and served via svnserve. With the above defaults, a third step is required, which can get tedious. I'd propose enabling svnserve by default, and it can then be disabled if required. This also maintains the ease of creating test scripts to try and reproduce issues.

As a user, I'm not interested in *ever* using mod_dav_svn, but always using svnserve, and the current command-line client works out-of-the-box.

Just my $0.02.

Daniel B.