On Wed, May 11, 2011 at 6:28 AM, Ryan Schmidt
<subversion-2011a_at_ryandesign.com> wrote:
>
> On May 11, 2011, at 01:48, Ben Simpson wrote:
>
>> I am running the current version of SVN on a CentOS 5.5 server, and am looking for the the default user config file location.
>>
>> What I am trying to do is set the default ~/.subversion/servers file to automatically not store passwords, but want to be able to set it once, and when new users access SVN (from this machine) they get the file that is already modified. I cant seem to find where it gets this file from originally.
>>
>> If this doesn't make any sense, let me know, and I will try and explain it better..
>
> There is no central server-side settings storage system. There is however the /etc/subversion directory (on the client machine) whose contents would be used as defaults on that client.
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html
First, upgrade to the CentOS 5.6 version of subversion, for both
clients and servers. *NOW*. That gets you Subversion 1.6.x, which at
least *ASKS* before storing those passwords in cleartext. It's a very
large improvement in flexibility and performance. Note that once you
touch a working copy with Subversion 1.6.x, it will auto-upgrade and
you cannot gracefully roll it back to the Subversion 1.4.2 on CentOS
5.5, so be ready to update all your hosts.
If you're running CentOS 4.x or 3.x, *STOP IT*. Upgrade before even
considering using Subversion on them anymore, there's been too much
development, and the backport is a nightmare.
Second, this is also an *old* hobby horse of mine. http/https password
mangement for clients in UNIX and Linux and CygWin is one of
Subversion's long-standing security vulnerabilities. (TortoiseSVN and
other Windows based tools apparently handle it much better.) The
svn+ssh client, at least, does not do this. The svn+ssh client also
allows the use of SSH keys, rather than login shells, that can be
locked to read-only access or permit write access, but funnel all
subversion access through a single authorized account, typically
"svn". If you want anonymous read access, you can make the
repositories live in /var/www/html/svn/.
The problem with svn+ssh access is key management. There remains no
Subversion equivalent of gitosis to central and gracefully manage SSH
keys, and developers can get pretty cranky if they have to wait to get
their SSH keys added. I'm hoping Wandisco's latest commercial
offerings for Subversion handle this: I'm asking questions about it
for other reasons, and they're deeply involved in the Subversion 1.7
development.
Received on 2011-05-11 14:06:25 CEST