Tag Archives: SVN

Simple Configuration Service

Posted by on October 15, 2012 3 comments

The Basics

So I’ve seen a few implementations of ‘config services’ being built in all sorts of {ruby,python,php,java} applications. It really gets on my nerves to see people implementing things that could be much simpler. As Engineers we should really strive to get the most simple product built in a flexible way. So here is my go at implementing a ‘config service’ (basically a key value store optimised for reads). This was originally tweeted in a set of four tweets (1, 2, 3, 4).

Tweet 1

A 'Config Service' that fits in a tweet:
<Location /config>
  DAV svn
  SVNPath /var/svn/config
  SVNAutoversioning on
</Location>

Simply place this in your apache server configuration. You’ll need to create the SVN repo, which can be done with ‘svnadmin create /var/svn/config’ then chmod it to be writiable and readable by apache. What we are doing here is turning on WebDAV (which lets us upload and make directories on the apache server) and turning on SVN backed autoversioning which means that every change we make will be recorded in the SVN repo.

Tweet 2

To get a variable:
curl -s http://config/config/namespace/key

This simply performs a GET request for a key. You can’t do this until you add some keys to the server.

Tweet 3

To change a variable:
echo "value" | curl -T- http://config/config/namespace/key

This creates/modifies a key. You will need to have the namespace created first, which is in the next tweet.

Tweet 4

Make a new namespace:
curl -XMKCOL http://config/config/namespace

This creates a namespace to put keys in.

Extensions

Users

The service above doesn’t support users, so anyone can modify the keys, and the svn logs look like this:

------------------------------------------------------------------------
r5 | (no author) | 2012-10-15 12:36:33 +1100 (Mon, 15 Oct 2012) | 2 lines

Autoversioning commit:  a non-deltaV client made a change to
/namespace/key
------------------------------------------------------------------------

All we need to do is require the user to authenticate when doing PUT requests to the server. You can use this method to restrict certain namespaces too. Generate a htpasswd file for the users and place it in /var/svn/users and change the code to read as follows.

<Location /config>
  DAV svn
  SVNPath /var/svn/config
  SVNAutoversioning on
  AuthName "Config Service"
  AuthType Basic
  AuthUserFile /var/svn/users
  <LimitExcept GET>
    require valid-user
  </Limit>
</Location>

Viewing the logs

Simply do this:

svn checkout http://config/config
cd config
svn log

You can also use this to make bulk/atomic changes in the same way you would make changes to a subversion repository.

Using Subversion for Assignments

Posted by on October 6, 2009 2 comments

If you’ve never heard of subversion before then you are in for a pleasant surprise. Subversion is a version control tool, which means it will keep track of several files and all their old versions. Normally subversion is used to help multiple people work together on a single project. It tracks all their changes and combines them all, even flagging when conflicts occur and assists in resolving them. It is also useful when working alone on a school assignment. Here’s a few dot points that capture the essence of why Subversion is useful with assignments:

  • Subversion allows you to work on the same assignment on multiple computers.
  • Subversion can email you with changes you’ve made, allowing to review them.
  • Subversion allows you to show a teacher that you’ve been working on an assignment over the whole time available and not just in the last few days. this gives you greater leverage when asking for an extension.
  • Subversion can help you prove in a disciplinary hearing that you did not plagiarise any code from others showing the natural growth your code had.
  • Subversion can get back that file you just accidentally emptied out of the trash.
  • Subversion can show you all the changes you made between the time you fixed that annoying bug, and now, when you just reintroduced it.

The first step to making an assignment in is to build your repository. If you didn’t do this first that’s okay, you can easily import an existing project into a subversion repository. To create a repository you simply use the ‘svnadmin create’ command. You should then create some folders that should be in every subversion repository (trunk, tags and branches). This next block of commands will show you how to create the initial project. If you’re using these instructions to import an existing project just copy your files into the trunk folder before you run the ‘svn import’ command.

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

The trunk, tags and branches folders aren’t strictly required but can be very useful in certain circumstances. The trunk folder is where you main copy sits, it should be the latest stable version of the software. In an assignment though this is where you will probably be doing all your work, you generally don’t have the need or the time to make and merge branches. Which leads us to branches. Generally you branch software when you are about to make a major change that may break other developers work. You most likely don’t have other developers on your assignment and if you do you’ve probably all decided on what parts you will work on. Finally tags are for labelling certain versions with a specific tag. For example if you have to submit your assignment weekly you could tag each week as you submit, or you could tag as you finish each requirement. To populate these folders you just copy whatever it is you want into them. Subversion will only use a minuscule amount of space as the copy will be stored internally to the repository.

Before you can edit the files in the repository you need to check it out. You can check it out to the same machine, you can use SSH or you could check it out over WebDAV depending how you’ve set it up. The following command checks out the trunk folder into a folder called newproject. This is one of the few times you have to type the full path to the repository. Subversion remembers this for you so that next time you use a subversion command its pre filled.

svn checkout file:///home/daniel/svn/newproject/trunk newproject

What you’ve just checked out is called a ‘working copy’. This is where you make your changes before uploading them again in to the repository. Your working copy also includes copies of the versions you originally checked out so that if you want to revert back to them you can. Because they are stored in the working copy you don’t need access to the repository to revert. To revert back to the version you checked out from the repository you simply run ‘svn revert <filename>’. You can also find the differences between these versions and the current ones by using ‘svn diff <filename>’. The filename is optional and if omitted will print all the changes in the current directories and below.

Part 2 to come…
Random Thought: I’ve just redesigned my website, I’d love to know what my readers think. If you could post your comment on the new design, I’d appreciate it.

Using Subversion over SSH

Posted by on September 23, 2009 1 comment

Subversion is an amazing tool that you can use to keep track of all the changes you make to a group of files. If you haven’t used it before, or have never heard of ‘version control’ then you should probably read the Subversion Book.

Few people don’t realise that subversion has the ability to connect to a remote repository via SSH. Its extremely simple and can give you all the advantages of storing your important files on a server while still having them readily accessible on your desktop. This means that for example you could have your files (and every old version of your files) stored on a RAID device on a server while working with them locally on your desktop.

To set this up its actually rather simple. First you create your repository and perform the initial import of the files. I usually make it in my home directory as follows:

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

These commands are basically what you’d use to create any subversion repository and people familiar with it require no explanation. Most people probably even have is scripted to make it just that much easier. Here comes the fun part though. Next we (on our local machine) check the files out. To checkout subversion repositories over ssh you simply use the following command:

svn checkout svn+ssh://username@servername/home/daniel/svn/newproject/trunk newproject

All going well you will now see a password prompt and upon successful authentication the files will be checked out. This is all that is required and from now on you can simply use the ordinary svn commands.

Random Thought: … and I says to the kernel developer, I says “git this!”