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

Re: Expected performance (svn+ssh)

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Mon, 08 Jul 2013 17:10:14 -0400

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.



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.
Received on 2013-07-08 23:11:03 CEST

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.