subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: svnadmin create and not being method agnostic
Date Tue, 04 Jan 2011 22:25:23 GMT
On Wed, Jan 05, 2011 at 07:56:48AM +1000, Daniel Becroft wrote:
>  On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling <stsp@elego.de> wrote:
> > = 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?
> 

Whatever svnserve.conf says is independent of what this proposed
servers.conf would do.

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

Disabling service by default was, as far as I understood, one of the
main points of Nico's and Philip's requests.

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

Sure, fine with me. I don't think the proposed feature is required at
all. I just wrote this proposal to show one fairly adequate way of how
the requests made by Philip and Nico could be addressed.

Stefan

Mime
View raw message