On Wed, Jan 05, 2011 at 07:56:48AM +1000, Daniel Becroft wrote: > On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling <s...@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
