On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling <stsp_at_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.
>
> 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.
>
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
> #[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.
>
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.
Cheers,
Daniel B.
Received on 2011-01-04 22:57:48 CET