Things n' Stuff Thoughts about the universe in general

When you want to host a Subversion repository on your CentOS (or RHEL) server, its quite annoying that the only options available to serve your repository are SSH (using the svn+ssh:// schema in the Subversion URLs – it is basically set up out of the box, not tweaking necessary) and Apache’s mod_dav_svn (using the http:// or https:// schema in the Subversion URLs – this is somewhat complex to setup but good instructions are easy to find on the web).

The main advantage of either of these methods is security: both have easy transport security (SSH by default, Apache if you set it to server over SSL) and are easy to setup authentication for (SSH authenticate against the system’s accounts using PAM and Apache authenticate against basically anything with a simple setup).

The main disadvantage of these methods are that they are slow (SSH is apparently somewhat faster then HTTP) and when supporting multiple large projects of many developers I started running into all kinds of weird connection errors when you try to manipulate many files on many projects at the same time.

Subversion itself offers another alternative using their own network service called svnserve – this is a standard unix daemon that listens on a specific port¹ and uses a native protocol to communicate with Subversion clients (using the svn:// schema in Subversion URLs). It offers very good performance, but no transport security (encryption) by default. Another major problem with using svnserve as a network service is that while CentOS ships the binary itself (it is required as part of the way that the svn+ssh:// protocol is implemented) it doesn’t ship any support files to run it as a standalone service nor to help with its configuration. Also by default svnserve can only authenticate users using its own Apache-style password database file – which makes it unsuitable to integrate in large organizations.

(more…)

1. port 3690 by default [↩]

This is another “how to” tech article, anyone who is not interested in such things may stop reading now.

VirtualBox is a great virtualization software (hypervisor as the lingo currently goes) – I believe it matches up nicely against the current VMWare Workstation line and they offer both an open source version which is free for any use as well as a commercial version (with some added features such as SATA support) that is free for personal use.

VirtualBox allows you to take snapshots of the current VM state so that you can safely return to a previous state of your VM if you messed something up (for example – installed too much software on your Windows XP VM). Unfortunately, unlike what the VirtualBox UI will have you think, the snapshot features allows you to take progressive snapshots but you can’t fork your snapshot tree – you can’t create branches off old snapshots. Snapshots which are not current can be either discarded (have their state merged into another state) or reverted too (discard all the newest data and return to the old state).

Additionally, you can’t copy (clone) VMs with snapshots except copying the oldest state¹.

(more…)

1. which is most often not what you want. If you don’t mind discarding all of the old snapshots, you can clone the current VMs state using the method described in this VirtualBox forum thread [↩]