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_at_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
Received on 2011-01-04 23:39:13 CET