SVN for not hardcore programming geeks

Programmers are like chess players in that “there are only two kind of people: chess players… and the others”.

I’m (un?)fortunately part of the others, more focused in breaking stuff or tearing things apart and looking at the pieces (something not surprisingly similar to particle physics ;)). Anyway I need to do some light programming as a part of my researchducation, mainly a bit of python ctypes or a couple of C snippets. The problem, of course, is that I used several machines every day. I have a netbook which I use on the way, I laptop at home and two or three virtual machines where I run/analyze malware or other software.

Yes, the code gets quickly spread all over the computers and I have different versions in each one of them. “Didn’t I fix that already? Where is it?” are the usual questions I ask myself.

Time to organize this mess a little bit. Even I’m not a programmer I can take profit of the tools designed for them, for example, Subversion (SVN).

The idea is to have a central repository of code (and/or binaries) with a version control system and copies wherever you need it which will be in sync with it.

Since I happen to be working a lot in Windows environments lately (boo!), I had to find a solution, at least for the clients, which worked fine there. For the server I would use just the standard “subversion” package in my already set up Ubuntu Server 9.10.

The clients will be using Tortoise SVN, which is powerful, easy to use and hyper cute.

Here is how I set it up.

The SVN server on Ubuntu.

# apt-get install subversion ;)

# svnadmin create /opt/svn/programming

This will create an empty repository. This means, empty of files to be versioned but you can see the svn database which will hold your files later.

carlos@ubuntu-server-1:/opt/svn/programming$ ls -l
total 28
drwxr-xr-x 2 www-data www-data 4096 2010-09-15 14:51 conf
drwxr-xr-x 3 www-data www-data 4096 2010-09-15 22:16 dav
drwxr-sr-x 6 www-data www-data 4096 2010-09-17 23:33 db
-r–r–r– 1 www-data www-data    2 2010-09-15 14:51 format
drwxr-xr-x 2 www-data www-data 4096 2010-09-15 14:51 hooks
drwxr-xr-x 2 www-data www-data 4096 2010-09-15 14:51 locks
-rw-r–r– 1 www-data www-data  229 2010-09-15 14:51 README.txt

Now you need a way to connect to the repository from the clients. There are a lot of supported protocols, but I decided myself for old good http, since the code isn’t critical and I already have an Apache running on this machine.

In order to make the repo available through http you need to add the following config to your apache default site:

<Location /svn>
DAV svn
SVNListParentPath on
SVNParentPath /opt/svn
AuthType Basic
AuthName “Subversion repository”
AuthUserFile /opt/svn/.htsvnusers
Require valid-user
</Location>

You can see the authentication config. Well, I said the code isn’t critical but some form of access control must be! This is basic Apache authentification, so you can create the file htsvnusers like this:

# htpasswd -c /opt/svn/.htsvnusers carlos abc123   (*)

(*) The parameter -c is just needed for the first time to create the file.

Now is time to configure the Windows clients. This is pretty easy, since Tortoise SVN is a shell extension. That means, the whole interaction with the program is done via the “right-click menu” on the Window Explorer.

Create a folder where you want to store your “working copy” of the project, right click when in it and select “checkout”.

Checkout is the SVN terminology for “first import and creation of the local working copy”. Once you have your working copy, the option for checkout will disappear, since it doesn’t make sense anymore. Instead you’ll have all this options, some of them pretty neat, like “Show Log” where you can track the evolution of your project or “Diff with previous version” (only if you click on a file), among others.

The most basic (and important!) two you will be using continuously are located on the main menu.

  • SVN Update: make sure to use this everytime you start working on a local copy to get always the last version of a document.
  • SVN Commit: this sends the new version to the Subversion server, do this everytime you have finished working on the local copy (or every now and then, after relevant changes)

It’s important to note that everytime you commit you are forced to enter something into a comment field. Get used to it and write clear, concise comments that help you to remember what the changes were even after long periods of time!

Happy (evil) coding! ;)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s