Thursday 10 December 2009

Creating a Simple Subversion Server on Ubuntu

For a while I have been trying to learn some programming skills. It is something I would like to do purely for fun and if I can get to a stage where I have decent programming capabilties then I can enjoy writing applications and perhaps start giving something useful back to the Linux community.

To start with the best intentions, I decided to set up a simple Subversion version control system on my server to allow me to keep control of my programming progress in an orderly manner. This blog entry just simply describes how I went about setting it up.

Subversion is a version control system which one can use to keep track of a project and have the ability to 'check out' stuff to work on then 'check in' the changes, keeping old revisions of work in case you need to revert back to an earlier version. This is great, especially when learning, as you don't need to keep saving new copies of your program as it develops every time you want to try something new in case you mess it up and need to revert back to your previous version.

You work on one file (or multiple) and keep checking in your changes, creating many versions which you can always fall back on, but in your working area, you just see the latest version.

I am sure more experienced users may well spot flaws in my set up, but for now, as a beginner, it works well enough for me.

Firstly, I am using an Ubuntu 8.04 LTS server on a VPS. To set up subversion, I followed the following steps:

Install and Setting up Subversion

  1. Firstly, install subversion, easily done with: sudo apt-get install subversion
  2. Then set up a location where subversion will create and manage your projects. I created a directory in my home directory called 'svn'.
  3. Then create another directory within 'svn' to hold the repositories, e.g. 'svn/repos'.
  4. Then create a group for subversion, in this case I chose 'subversion'. I used the command (as root) addgroup subversion
  5. Then change the ownership of the directory 'svn' and all within to the new group: chgrp -R subversion /path/to/svn
  6. Next add write permissions of memebers of the group to be able to write to 'repos' directory: chmod g+w /path/to/svn/repos
  7. Next, to make sure everything created within svn/ is owned by the group: chmod g+s /path/to/svn/repos
  8. Then add users that you want to allow to use subversion to the group: adduser <user> subversion

Creating Repositories

Now we can add some projects or repositories to subversion to work with. A project can contain a single file or multiple files, so for one of my first projects, I have multiple different programs where I have just been experimenting; they are all under one project or repository.

To create repositories:

  1. Go to the repo directory: cd /path/to/svn/repos
  2. Before creating a repository, set the umask to '002'. This allows the following created files to have the correct permissions: umask 002
  3. To create a repository called 'project1' execute: svnadmin create /path/to/svn/repos/project1
  4. Reset umask: umask 022
  5. Now the new repo is created, go to some location elsewhere (you don't work in the repo directory, this is where subversion keeps all its data) and checkout the initial version: cd /path/to/somewhere/eg/home/user/wip If working locally, i.e. on the server where subversion server is running: svn co file:///path/to/svn/repos/project1 This will check out the current revision of the project, which at this stage is revision 0. It will create a directory named 'project1' wherever you perform the command.
Now you can create or copy existing work into this directory and do whatever you want until it is time to check your work in.

Working with Repositories

As we just checked out the first version of project1 and added some files into it, we now need to check in the work to save it in is current state.

  • Firstly we need to 'add' the files to the project. Working within the working directory: svn add file1 file2 etc This should confirm it has added the selected files to the project.
  • Next we have to 'commit' the changes. This saves the data of the current iteration of the project to the subversion server.
  • svn commit -m "Add a note here to describe your changes" This should confirm to you it is adding files and uploading them and its current revision, in this case, 'revision 1'.

    Now another user (who is in the subversion group) can check out the latest revision somewhere else on the system by performing the same commands and it will create a working directory and copy all the files we initially added for them to work on, at revision 1.

    If someone else does work on the project and updates it with changes, we need to be able to get the latest revision to work on. To update your local working copy to the latest revsion, simply go to the working directory, e.g. /path/to/wip/project1 (not in svn/repos/) and: svn update This will pull down and overwrite the local copies with the latest revision.

    Checking Out Remotely

    More than often, you might want to work on your project on a local machine, i.e. not logged into the server, especially if working on GUI apps. The way I am doing it is via ssh. This means that only users with an account on my server and ssh access can download repos.

    I do this with the following command (after setting up and getting into a suitable working directory locally): svn co svn+ssh:// This then prompts me for my ssh password twice and then downloads the latest revison of the project to my local directory.

    I can then use the same commands to add, commit and update this directory.

    Non Standard SSH Port

    One note worth adding, I use a non-standard port for ssh access to my server. To allow for this when using the ssh method I needed to edit ~/.subversion/config

    Find the section titled '[tunnels]' and uncomment/add/edit the line containing 'sshtunnel' within to look like: ssh = ssh -p <your port number>

    This will allow the svn+ssh method to work with your non-standard port number.

    Hope this helps someone and also if more experienced users read this and think I am doing things wrong or giving out misleading information, please do let me know so I can update this information and also my own set up!

    No comments:

    Post a Comment