subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: svnadmin create and not being method agnostic
Date Tue, 04 Jan 2011 20:08:19 GMT
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.

Mime
View raw message