Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 98893 invoked from network); 4 Jan 2011 21:57:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jan 2011 21:57:38 -0000 Received: (qmail 48729 invoked by uid 500); 4 Jan 2011 21:57:37 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 48709 invoked by uid 500); 4 Jan 2011 21:57:37 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 48702 invoked by uid 99); 4 Jan 2011 21:57:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 21:57:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of djcbecroft@gmail.com designates 209.85.216.43 as permitted sender) Received: from [209.85.216.43] (HELO mail-qw0-f43.google.com) (209.85.216.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Jan 2011 21:57:30 +0000 Received: by qwk3 with SMTP id 3so14304871qwk.16 for ; Tue, 04 Jan 2011 13:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=hYmNCOvlLoPkCKKio/hesKY2LdO+T0QSDF/npgPioNc=; b=uBSN87x0uw0kyZGVXQZnUjlLg7wmC7fP7k8jJSGqrdwM/HtmM1A9R0gUlR9bMx6I0m 7r3SZbg+KcdGSUgu0fdl1ZFowVBmXpGYX82FkZSx1g7p/VwKTOpk+biy2WENo112/bE3 ST2uWIrYUCsXtpVY3f3tr0s0AS1ZvR4JFJCHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Tb3bjNTG8gG/1Ur/zf+J3uFRtPS9n6HzXmPKULxMja+QI0A/8/WckS3AZmasvqOK0i dxM2bBoYHT1SoaA33QMRJSwK7uI77VOJt2XxyKmFNFV9w7puh5RsgxkfVu8nBf0MbRGa Ugqbffmimy6Kv7FXvV+qqaZrk/cxsTD3SL4JU= Received: by 10.229.214.76 with SMTP id gz12mr19775122qcb.8.1294178229641; Tue, 04 Jan 2011 13:57:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.218.212 with HTTP; Tue, 4 Jan 2011 13:56:48 -0800 (PST) In-Reply-To: <20110104193510.GB16313@ted.stsp.name> References: <4D1A1743.9060708@redfish-solutions.com> <20101228172409.GG14809@ted.stsp.name> <20101229160113.GG30723@ted.stsp.name> <4D1B69D4.1060405@redfish-solutions.com> <20101230142911.GA12126@ted.stsp.name> <4D202201.9050107@redfish-solutions.com> <20110103133508.GG8919@ted.stsp.name> <20110104193510.GB16313@ted.stsp.name> From: Daniel Becroft Date: Wed, 5 Jan 2011 07:56:48 +1000 Message-ID: Subject: Re: svnadmin create and not being method agnostic To: Philip Prindeville , Nico Kadel-Garcia , Ryan Schmidt , users@subversion.apache.org Content-Type: multipart/alternative; boundary=00163628410ca7632e04990c5971 X-Virus-Checked: Checked by ClamAV on apache.org --00163628410ca7632e04990c5971 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling 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. --00163628410ca7632e04990c5971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 5:35 AM, Stefan Sperling = <stsp@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. =A0As l= ong 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 tracke= r.
Maybe someone will like the idea and will eventually come up with a patch.<= br>
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 happe= n.
So I hope you don't feel put off by it.

Stefan

=3D=3D=3D=3D

=3D Proposal: New servers.conf configuration file in Subversion Repository = =3D

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<= br> 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
=A0 that has incorrectly been configured to serve the repository
=A0 (repositories need to explicitly opt-in to being served by a particula= r SI)

B) moving repositories from one SI to another in the case where multiple =A0 repositories are each served by one and only one of several SIs,
=A0 without changing the server configuration or repository location

To realize use case A, admins currently have to:
=A0- understand configuration mechanisms of all SIs in order to
=A0 =A0enable or disable repositories per SI
=A0- make sure that repositories that shall be served by a particular
=A0 =A0SI are only readable and writable by processes of that SI, and not<= br> =A0 =A0by any other processes (each such process could be a misconfigured<= br> =A0 =A0Subversion 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 reposito= ry.
This provides a layer of protection against accidental server misconfigurat= ion.

To realize use case B, admins currently have to:
=A0- understand configuration mechanisms of all SIs in order to
=A0 =A0enable or disable repositories per SI
=A0- either move repositories around in the server filesystem
=A0 =A0or 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.

=3D Impact on the repository format =3D

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 existin= g
configuration file parsers in the Subversion code base can be used.

What's the impact of using svnserve with a --config-f= ile argument?
=A0
The default content of this file is as follows:

=A0# This file specifies which Subversion server implementations
=A0# may serve this repository.
=A0#
=A0# Uncomment the following lines to enable serving by mod_dav_svn
=A0#[mod_dav_svn]
=A0#enabled =3D yes
=A0#
=A0# Uncomment the following lines to enable serving by svnserve
=A0#[svnserve]
=A0#enabled =3D yes

So, by default, serving for the repository is disabled.

Shouldn't the current behaviour of 'svnadmin create' be maintai= ned? 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=20 defaults, a third step is required, which can get tedious. I'd propose= =20 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 issu= es.

As a user, I'm not interested in *ever* using mod_dav_svn, but always= =20 using svnserve, and the current command-line client works=20 out-of-the-box.

Just my $0.02.

Cheers,
Daniel = B.
--00163628410ca7632e04990c5971--