subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Harold <thomas-li...@nybeta.com>
Subject Re: Expected performance (svn+ssh)
Date Mon, 08 Jul 2013 21:10:14 GMT
On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
>
> That box has more than enough CPUs (forty), cores are barely utilized.
> How is the access over ssh can be configured? I thought it's only
> http(s) or svn proto.
>

http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls

http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks

svn+ssh access has some upsides and downsides.  For us, it was simpler 
to get up and running with it back in 2007 when we were still getting 
our feet wet with SVN 1.4.  We weren't ready to muck around with Apache 
httpd and SSL certificates to do https access to the repository.

We grant access at the repository level via Linux file system 
permissions.  This means that every user needs to have their own system 
account and belong to Linux group that owns the repository.

chown -R svn-group1 /var/svn/svn-repository1
chmod -R 770 /var/svn/svn-repository1
chmod -R g+s /var/svn/svn-repository1

Where the 770 is some combination of, 770, 775, 755, 750, 700.

770 = owner read/write, group read/write, other none
750 = owner read/write, group read-only, other none

To keep things sane, we do not set permission by hand, but edit a script 
that can be re-run to fix permissions on the repositories.  Most of our 
repositories follow a set naming pattern, which makes it easier.

The other advantage of svn+ssh is that it works well when using FSVS, 
because you can edit ~/.ssh/config so that FSVS can login to the SVN 
server automatically and push/pull configuration file changes.

Mime
View raw message