With the introduction of Samba, we have taken another step towards computer backup, sharing and sync bliss.  And while a Samba share greatly improves life by providing shared access to files, it is only a small part of effectively sharing and syncing.  In this article, I will introduce another major pillar of the setup: Subversion.  I will also explain how to configure your home server to act as a central subversion store which can be accessed from any computer in the house.  A separate article will describe why you should care and how you can effectively leverage Subversion’s power.  This article builds on steps taken in Part 1 of this series where we have already downloaded and installed the software needed for a functional Subversion setup.  In this article, we will take a look at how to configure it.

Components

There are two important components to a working Subversion installation.  These are: 1) the Subversion client which tracks individual changes and handles archiving; and 2) the http server.  A specific apache2 extension works with the already installed Apache server so that you can access your repositories through a web connection (all made possible through the magic of WebDAV).  Put into English, this means that the files in your Subversion repository will be available over http (the same way that your browser retrieve information from the internet).  Http access has one huge advantage: if your home server is accessible from the internet, you can get at anything stored in your repositories.  (While convenient, it is far more complicated to set up a web server and configure it for secure outside access than it is to set up a simple home file server.  Creating a publicly available subversion repository is therefore outside the scope of this article.  For more information about setting up a home web server, you can find a  good overview here.)

Both components needed for remote access have already been downloaded and installed on the server (Part 1).  To configure them and get them working is a two step process: 1) We need to create a repository for your project, and 2) we need to configure the Apache web server to allow access over http:// (or https://).

(Note: Though it is covered more in depth in Part 1 of this series, the necessary software can be installed by typing: sudo apt-get install subversion libapache2-svn.)

Repositories

A repository is a centralized file store for one or more projects.  A project is typically a folder of related items, though it doesn’t have to be.  When a file or folder is added to a repository, all of the changes to that file or folder are tracked.  So, when setting up your repositories for the first, time we have a couple of options.

1. A single repository for all projects. This first option can be used to group, backup and sync important notes and other things that may not have a closely related theme. 
2. Separate repositories for each individual project.   This option can be valuable for keeping the files of a particular project together

I personally use both options.  I have one repository that contains important information that I want to keep backed up.  This includes receipts and miscellaneous notes.  I also create repositories for large projects that I am currently engaged in.  I have one repository for manuscript drafts, another for data sets that need to be updated, and a third for source code.  I’ve recently begun work on a book, which also has it’s own repository.

A software repository must be set-up directly on the machine where it will be stored.  Therefore, we will need to use the command line at the server directly or via secure shell (ssh).  A brief guide on accessing your server via ssh can be found in Part 1.

Typically, a Subversion repository should be placed in a shared directory so that all users on the server will have access to it.  It is possible to create separate repositories for each user, but that is substantially more complicated and beyond the scope of this document.  Therefore, if you have followed the general setup described in this series, I would recommend that you create your subversion repository on one of the external hard disks.  My subversion repository is on the disk mapped to /media/store.  Creating the repository on the external hard drive greatly simplifies issues relating to permissions and ownership (The two areas which serve as the most common sources of errors.)  In the set-up examples below, the name of my repository will be MyProject.  The following series of commands will create the parent SVN directory and the MyProject directory:

sudo mkdir media/store/SVN

cd /media/store/SVN

sudo mkdir MyProject

Now check the permissions of the folder that you just created by typing:

ls –l /media/store/SVN

You should see something like this:

total 0

drwxrwxrwx 1 root root 0 2009-02-14 17:04 MyProject

The permissions information and folder information is found on the left.   In the example above, all users of the computer are able to access the folder and modify its contents.  This is an acceptable configuration for my server because it is behind a physical firewall and isn’t visible to the outside world via the internet.  However, you may opt for a more secure setup.  To do this, create a specific “subversion” group and add only those users who require access.  The Ubuntu Subversion documentation provides a good overview on how to do this.

Once the permissions have been configured to your liking, you can create the SVN repository by typing the following:

sudo svnadmin create /media/store/SVN/MyProject

Additional repositories are added by creating other folders in the /media/store/SVN directory and then running the “sudo svnadmin create” command.

Access via http

While a repository can be checked out through many different methods (directly on disk, via http(s):// or svn://), I find access via http(s):// to be the most convenient.  Both http:// and https:// can pass through most firewalls without problem or additional configuration.  This is good as networking in general and firewalls in particular can be an area of deep demon magic.  I have spent many hours trying to correctly configure my firewall for other protocols (most notably svn or svn+ssh) without ever getting a  connection.  Should you desire to use one of the other protocols, there is ample information about configuration options available <
a href=”http://svnbook.red-bean.com/”>here.

The libapache2-svn extension to the Apache Web Server is what makes http access possible.  This extension is installed by typing:

sudo apt-get install libapache2-svn

Once the package has been installed, it needs to be pointed to the SVN repositories that we just created.  We do this adding the following text to the /etc/apache2/mods-available/dav_svn.conf file:

<Location /svn>

DAV svn

SVNParentPath /media/store/SVN

SVNListParentPath On

AuthType Basic

AuthName “Subversion Repository”

AuthUserFile /etc/subversion/passwd

<LimitExcept GET PROPFIND OPTIONS REPORT>

Require valid-user

</LimitExcept>

</Location>

The third line, following SVNParentPath is the path to the SVN folder created in the precious step.  My SVN folder is found at /media/store/SVN.  If you would like all of your  repositories to be available through http:// access, you must place them in the SVN folder.

Once you have added the above lines to the config file, you will need to restart the apache web server.  You can do this by typing the following:

sudo /etc/init.d/apache2 restart

Next, we need to create the /etc/subversion/passwd file (which contains user log-on information).  Since we just installed SVN, the passwords do not yet exist.  As a result, the first SVN user will need to be added with the –c option.  Additional users can be added normally.  For the first user, type:

sudo htpasswd –c /etc/subversion/passwd user_name

Substitute the correct credentials for user_name.  When I create WebDav users, I typically use same credentials created for the server account.  But again, the username and password can be anything that you want.  Next, the server will prompt you for a password.  Enter something appropriate.  Additional users can then be added by typing:

sudo htpasswd /etc/subversion/passwd user_name2

After you have run this last step, you are now able to access your repository through regular http.  You can now access your files by using TortoiseSVN, RapidSVN, or via the command line:

svn co http://hostname/svn/MyProject –username user_name

Even though this configuration is convenient, there are a few security issues which you should be aware of.  First: if your server is directly accessible via the internet, you will want to create a specialized “subversion” group and modify the folder permissions appropriately (see above).  Second, when accessed via http, your username and password are sent as simple text.  If you need ssl encryption (https://) or want additional security, you will need to install and configure a digital certificate for your server.  You can find additional information on how to do so here.  For more information on using Subversion like how to add and edit files, check-in modifications, and update other computers, check out this article.

Using the right tool

While Subversion is a fantastic tool for backing up and syncing files, it isn’t the best solution for all projects.  Other services including DropBox and Windows Live Mesh accomplish these goals without some of Subversion’s headaches.  Both DropBox and Mesh automatically sync all files in watched folders.  Subversion, in contrast, requires that new files be added manually.  Another major difference is how often changes are sent to the backup server or other computers.  In Subversion, changes from one computer must be checked in and updated manually.  DropBox and Mesh also handle these two tasks automatically.

Yet, while DropBox and Mesh handle file backup and sync automatically, they do not keep a comprehensive history of changes or allow for you to revert to previous copies should something disastrous happen.  Sure, Subversion requires an upfront commitment in effort, its change tracking feature is a lifesaver for difficult or complex projects.  As a quick example, while recently working on a major paper revision, I decided that an earlier draft was preferred over a more recent version.  Because the paper was under version control, finding the previous version of the paper was an extremely simple thing to do.  This is something that wouldn’t have even be possible with Mesh or DropBox.

Conclusion

Congratulations!  You now have a fully functional Subversion server.  More importantly, all of the software on the server is now set up and ready for use.  With Samba, you should be able to share files and music between your home computers.  With Subversion, you have instant backup and change tracking for important files and folders.  It’s time to start talking about the third pillar of our set-up: backup.  In future articles, we will look at how to configure client computers so that they create automated back-ups to your just configured Samba shares.

Tags: Subversion
Categories: Computer, Cool Stuff
3 Comments »