The best Subversion documentation is the Subversion book. It can be found at http://svnbook.red-bean.com.
When you go to use Subversion, you'll have to choose a URL that your repository will be accessible under. You have a few options: ssh, location tag in apache, virtual host with apache:
This method of access requires the users to be able to access the system shell. The authentication will be done against PAM, usually to the /etc/shadow password database.
Choose a location to store your svn repositories. /var/svn is a recommended place:
mkdir /var/svn ; cd /var/svn
Create the new repository:
svnadmin create repos
A few permissions must be set in that directory so your shell users are able to use this repository. Run the following commands to do that:
groupadd svn
chgrp svn repos/ -R
And in order to preserve permissions:
chmod g+sw repos -R
In order to let your users access the repository, they must be added to the group svn. So try this:
- Creating a new user:
adduser rimutest
usermod -G svn rimutest
- Verifying it works, from a remote client
root@staff:~# svn co --username=rimutest svn+ssh://<your address>/var/svn/repos
OR TRY
svn co svn+ssh://rimutest@YOUR_IP/var/svn/repos
Note: in case the SSH daemon listens on some other port than 22, you need to tell that to svn. The easiest way would be to set the SVN_SSH global variable. In bash you can do that like this:
export SVN_SSH="ssh -p 1234"
Another useful command is 'svnlook info /path/to/repo'
Say you have created a repository (on your server):
cd /var/svn
svnadmin create repos
On your PC you have a myproj directory.
Import that into your subversion project with:
# cd the directory 'above' myproj
svn import myproj svn+ssh://yourip/var/svn/repos/myproj/trunk
Then move that original myproj directory out of the way, and checkout the code you have just imported:
mv myproj orig.myproj
svn checkout svn+ssh://(user_if_different@)yourip/var/svn/repos/myproj/trunk myproj
By using the HTTP method, you'll be able to use a separate authentication database, usually an htpasswd file, instead of using local (shell) user authentication.
No matter whether you'll use <Location> or <VirtualHost> for configuring http access to the svn rep, first you have install the required packages:
For Red Hat-based distros, including Fedora:
apt-get install mod_dav_svn subversion
/etc/init.d/httpd restart
For Debian-based distros, including Ubuntu:
apt-get install libapache2-svn
a2enmod dav_svn
/etc/init.d/apache2 restart
Then configure access from apache to your repositories:
mkdir /var/svn
chown apache /var/svn -R
For Debian-based distros, set "www-data" as the user instead of "apache".
Create the repository:
cd /var/svn
svnadmin create repos
You must also create a HTPasswd file for using with this repository, using the htpasswd command. Be careful with the -c parameter - you should only use this option when creating a new htpasswd file.
Reference: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd
htpasswd -c /etc/subversion/repos.htpasswd rimutest
This is the simplest way to configure SVN for using with Apache. Add this to your Apache config:
<Location /svn/repos>
DAV svn
SVNPath /var/svn/repos
AuthType Basic
AuthName "repos"
AuthUserFile /etc/subversion/repos.htpasswd
Require valid-user
# or use this to allow anonymous read access
# <LimitExcept GET PROPFIND OPTIONS REPORT>
# Require valid-user
# </LimitExcept>
</Location>
Your subversion repository will be accessible at http://<your server>/svn/repos.
If you're setting it up under Apache2, using a VirtualHost subdomain, your configuration might look something like this:
<VirtualHost *:80>
ServerName svn.example.com
DocumentRoot /var/www/someplace
<Location /repos/>
DAV svn
SVNPath /var/svn/repos
</Location>
</VirtualHost>
Using this configuration, you'll be able access the repository at http://svn.example.com/repos/, and everything should work fine. But what if you don't want your repository to be at a subdirectory - what if you want it as http://svn.example.com/, as in:
<Location />
This can be done, but you'll likely run into a couple of issues.
Firstly, the folder that you specify as DocumentRoot (/var/www/someplace in the above example) must be accessible, even though it's never actually used. It should be completely empty - otherwise files in the directory and in the repository will clash, and you'll get a '301 Moved Permanently' when you check them out.
Secondly, there's a bug in the standard client library that isn't scheduled to be fixed in the near future. Every now and then you'll get an out of date error when trying to commit changes, even right after updating. It's easy to fix (delete everything in the working copy's .svn/wcpropcs/), but annoying. More details are at http://subversion.tigris.org/issues/show_bug.cgi?id=1851
A final thing to watch for is ErrorDocument. If you've got a custom 404 ErrorDocument that's enabled under the repository location, you might be faced with '500 Cannot load the requested SVN filesystem' - solve this by reseting the ErrorDocument directive in the Location block; a working configuration is below:
<VirtualHost *:80>
ServerName svn.example.com
DocumentRoot /var/www/emptyfolder
<Location />
DAV svn
SVNPath /var/svn/repos
ErrorDocument 404 default
</Location>
</VirtualHost>
If you installed rails, using our rails.sh script, you'll find that Ruby is installed here:
# which ruby
/usr/local/bin/ruby
We normally install subversion per the distribution packages.
# which svn
/usr/bin/svn
Both Debian and Red Hat based distros have a package for the svn ruby bindings.
On Debian (Etch), you can install them with apt:
# apt-cache search subversion ruby
libsvn-ruby - Ruby bindings \for Subversion (dummy \package)
libsvn-ruby1.8 - Ruby bindings \for Subversion
# apt-get install libsvn-ruby
[...]
The following NEW packages will be installed:
libsvn-ruby libsvn-ruby1.8
Only thing is Ruby won't find them where dpkg puts them, so you'll need to make some symlinks. It may vary a little on different systems, and haven't tried it on ubuntu, but you'll need some links like this:
# ln -s /usr/lib/ruby/1.8/svn /usr/local/lib/ruby/site_ruby/1.8/i686-linux/svn
# ln -s /usr/lib/ruby/1.8/i486-linux/svn/ext /usr/local/lib/ruby/site_ruby/1.8/i686-linux/svn/ext
On an x86_64, they looked like this:
# ln -s /usr/lib/ruby/1.8/svn /usr/local/lib/ruby/1.8/svn
# ln -s /usr/lib/ruby/1.8/i486-linux/svn/ext /usr/local/lib/ruby/1.8/svn/ext
After making these links I got a happy:
irb(main):001:0> require 'svn/core'
=> true
Getting errors like this:
[root@example ~]# svnadmin create foo
svn: Berkeley DB error while creating environment for filesystem foo/db:
Function not implemented
svn: bdb: unable to initialize mutex: Function not implemented
svn: bdb: foo/db/__db.001: unable to initialize environment lock: Function not implemented
Then you may be on a server with TLS/NTPL disabled/unavailable (e.g. no /lib/tls directory). This is typically the case on a UML VPS, and sometimes on Xen VPS (which can run TLS, but with a performance penalty).
The solution is to specify a non-berkleydb storage type for the repository. This is available in newer version of subversion (e.g. 1.1?)
svnadmin create --fs-type fsfs foo # other --fs-type option is bdb