This page has been automatically translated using the Google Translate API services. We are working on improving texts. Thank you for your understanding and patience.
We will see how to install, configure and maintain a private Subversion server within our local network. We will use a Linux environment, normally running on a low cost/power machine like a Raspberry-Pi.
1. Server Installation
First of all we are going to install and configure the Subversion server, as well as one or several working repositories within it. These repositories will work independently and can host different projects in each of them.
On Debian-based systems, we get and install the packages using the apt-get command:
sudo apt-get install subversion
Next, we create the working directory /srv/repos/svn where the repositories will be stored:
sudo mkdir -p /srv/repos/svn
2. Create a repository
To create a new repository, in the previously created directory, we do:
cd /srv/repos/svn
sudo svnadmin create myrepo
We register users with their passwords:
cd myrepo
cd conf
nano passwd
### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
[users]
user1 = <password_user1>
user2 = <password_user2>
user3 = <password_user3>
From the same conf directory, we edit svnserve.conf and enable the following options. The first prevents unauthenticated user access to the repository (by default it allows read access). The second authorizes authenticated users to make changes, and the third activates the key file that we previously edited.
pwd
/srv/repos/svn/myrepo/conf
nano svnserve.conf
### The anon-access and auth-access options control access to the
### repository for unauthenticated (a.k.a. anonymous) users and
### authenticated users, respectively.
### Valid values are "write", "read", and "none".
### Setting the value to "none" prohibits both reading and writing;
### "read" allows read-only access, and "write" allows complete
### read/write access to the repository.
### The sample settings below are the defaults and specify that anonymous
### users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
anon-access = none
auth-access = write
...
password-db = passwd
3. Migrate an existing repository
Instead of starting from scratch, we may want to migrate an existing repository to the new machine. The first thing is to create a safe copy of the repository to migrate. From the machine where the original repository is located, we do:
Where [repo] is the repository name and [repo_copy] the copy name. Using hotcopy allows copying even when the original repository is active and receiving requests. Copying using cp or rsync is not recommended.
If necessary, you can package the copy with tar:
tar -czvf [repo_copy].tar.gz [repo_copy]
3.1. Copy via USB
To transfer the copy using an external USB drive, we insert the drive with a partition formatted in Ext4 and do:
fdisk -l
We should see a record where our partition appears, something like this:
Disk /dev/sdb: 7.5 GiB, 8022654976 bytes, 15669248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 63 15669233 15669171 7.5G 83 Linux
Then we create the mount directory (if it does not already exist):
cd /mnt
sudo mkdir usb
We mount the disk:
mount /dev/sdb1 /mnt/usb
And we make the copy
rsync -av [repo_copy]/ /mnt/usb/[repo_name]/
Where [repo_copy] is the name of the copy made with hotcopy and therefore safe. Once finished we unmount the USB:
umount /mnt/usb
And we extract the disk. We insert the USB into the target machine and mount it using fdisk and mount as indicated above. Now, we perform a rsync from the USB to the repository directory:
IMPORTANT: Don't forget the last slash (/) after each path in rsync. That is, the correct thing is /mnt/usb/[repo_name]/ and NOT /mnt/usb/[repo_name].
If you have packaged the copy, unpack with tar:
tar -xzvf [repo_copy].tar.gz
3.2. Copy over network
If both machines are on the same network, it is possible to run rsync over an ssh tunnel within the same one. To do this, from the destination machine we do:
In this case, 192.168.1.4 is the IP of the source machine. You will need to enter the root password of the source machine.
4. Run Subversion server
Finally we need to start the subversion server to be able to access the repositories from other machines on the same network. For this we do:
svnserve -d -r /srv/repos
Which will run a daemon that will allow access to all repositories hosted under /srv/repos. If we want to ensure that the server will ALWAYS be executed when the machine is started, we must create a startup script. To do this, we start in the /etc/init.d directory.
cd /etc/init.d
We create a script called svnserve:
sudo nano svnserve
And we copy this content:
#!/bin/bash
### BEGIN INIT INFO
# Provides: blabla
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: blabla
# Description:
#
### END INIT INFO
svnserve -d -r /srv/repos/
We record (Ctrl+X) and give it execution permissions:
sudo chmod +x svnserve
We add the script to the boot sequence
sudo update-rc.d svnserve defaults
Finally, we restart the machine, to check that everything is going well:
sudo reboot
On startup, the svnserve daemon should be running. We check it with:
ps -A | grep svnserve
575 ? 00:00:00 svnserve
We already have a fully operational subversion server. Now it is about creating or adding repositories in the /srv/repos/svn path as they are needed.
5. Backup
To create a backup of a Subversion repository we do:
Where [myrepo] is the name of the repository on which we want to make the backup and the destination directory of the copy. Using hotcopy allows copying even when the original repository is active and receiving requests. Copying using cp or rsync is not recommended.
