[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin create and not being method agnostic

From: Philip Prindeville <philipp_subx_at_redfish-solutions.com>
Date: Mon, 27 Dec 2010 13:28:34 -0800

On 12/27/10 11:34 AM, Ryan Schmidt wrote:
> On Dec 24, 2010, at 23:34, Philip Prindeville wrote:
>
>> Unfortunately, the documentation and utilities in a few places are less clear than they could be when discussing repository setup for svnserve versus svnserve+ssh versus apache.
>>
>> For instance, "svnadmin create" deposits various files there:
>>
>> conf/svnserve.conf
>> conf/passwd
>>
>> which are useful for svnserve... but not for Apache access.
> So if you're not using svnserve, just ignore those files.

We'd rather not have files laying around not serving a purpose... especially if in some future version they start being meaningful again and their contents implicitly grant some sort of access.

When securing a machine, you start by closing everything up, and then opening up just what you need to accomplish the mission. "Closing everything up" in this context would include removing unused configuration files.

In short, ignoring the files isn't an option.

>> What about adding a --method option to "svnadmin create"?
> If its only purpose would be to omit those two files above, then I don't think that's a good idea. It's not uncommon for people to change their minds about what method they want to use to serve a repository; why make it harder for users who want to switch to svnserve?

It wouldn't have to just omit those files. It could also write different comments to the files that it does create... including hints, for example, about how to populate authentication files with htpasswd or htdigest...

In our case, we're setting up a secured source repository inside our network, for outside access (via port-forwarding on our gateway).

There is zero to no chance that we'll be changing our minds.

-Philip
Received on 2010-12-27 22:29:20 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.