On Wed, May 11, 2011 at 6:28 AM, Ryan Schmidt <subversion-20...@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.
