Stop Letting SVN Merge Conflicts Kill Your Productivity

If I have to resolve one more tree conflict in Subversion because a developer renamed a folder while another edited a file inside it, I might just pull the plug on the rack myself. It is 2010. Distributed Version Control Systems (DVCS) are not just a fad; they are the standard for any serious development shop. If you are still relying on a central SVN server that acts as a single point of failure, you are doing it wrong.

But here is the catch. While GitHub is making waves for open source, many Norwegian enterprises are hesitant to push proprietary code to the cloud, especially on US-based servers. Between the latency to San Francisco and the looming shadow of the Patriot Act, the smart move for Scandinavian CTOs is self-hosting.

Today, we are going to build a rock-solid, private Git server using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). This setup gives you granular access control without the bloat, kept safely within Norwegian borders.

Why Latency and Disk I/O Matter for Git

Git is fast. Blazing fast. But it is also I/O intensive. When your team does a heavy git clone or when the server runs garbage collection (git gc), you are hammering the disk. Most budget VPS providers oversell their storage, putting you on crowded SATA drives sharing IOPS with fifty other noisy neighbors.

This is where infrastructure choice dictates developer happiness. At CoolVDS, we utilize high-performance RAID-10 SAS arrays and low-density node allocation. We don't overprovision. When you run a repack on a 2GB repository, it finishes before you can grab a coffee. Try that on a budget host and watch your iowait spike.

The Norwegian Legal Advantage

Data sovereignty is not just paranoia; it is compliance. Under the Norwegian Personal Data Act (Personopplysningsloven) and the oversight of Datatilsynet, keeping your intellectual property and potential user data on servers physically located in Norway (like our Oslo datacenter) simplifies your legal exposure significantly compared to hosting offshore.

The Architecture: Ubuntu 10.04 + Gitolite

We are using Gitolite. It is an authorization layer on top of Git that allows you to manage access via a single configuration repo. No need to create a Unix user for every developer. It is clean, secure, and auditing is built-in.

Prerequisites:

• A CoolVDS VPS running Ubuntu 10.04 LTS.
• Root access.
• Your local workstation's public SSH key (~/.ssh/id_rsa.pub).

Step 1: Install Git and Dependencies

First, update your package lists and install the core git binaries. We are also grabbing Perl, as Gitolite relies on it.

root@server:~# apt-get update
root@server:~# apt-get install git-core perl python-setuptools

Step 2: Create the Git User

We need a dedicated system user to handle the repositories. This user will own the data.

root@server:~# adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

Step 3: Install Gitolite

Gitolite isn't in the default Lucid repos yet in a stable form we like, so we will clone the source. This ensures we have the latest features for ACLs.

root@server:~# cd /tmp
root@server:/tmp# git clone git://github.com/sitaramc/gitolite.git
root@server:/tmp# cd gitolite
root@server:/tmp/gitolite# src/gl-system-install
# Move your public key to the server mostly easily via scp, then:
root@server:/tmp/gitolite# cp /tmp/your_admin_key.pub /home/git/admin.pub
root@server:/tmp/gitolite# su - git
git@server:~$ gl-setup /home/git/admin.pub

During the setup, hit Enter to accept the default config. Gitolite acts as a gatekeeper. It uses the authorized_keys file to map SSH keys to Gitolite users, restricting what they can read or write based on the config.

Pro Tip: Never edit the authorized_keys file manually once Gitolite is installed. You will break the automation. Manage everything through the gitolite-admin repository.

Managing Your Team

Now, go back to your local workstation. You don't log into the server to add users. You just push changes to a special repo. It is Git inception.

local$ git clone git@your-coolvds-ip:gitolite-admin
local$ cd gitolite-admin
local$ ls -F
conf/  keydir/

To add a new developer, "Lars":

1. Get Lars's public key (lars.pub).
2. Drop it into keydir/.
3. Edit conf/gitolite.conf to give him read/write access.

repo    cool-project
        RW+     =   admin
        RW      =   lars
        R       =   outsourcing-team

Commit and push. Gitolite's hook scripts immediately update the server configurations. It is seamless.

Why Hardware Matters (Even for Git)

You might think, "It's just text files, why do I need a powerful VPS?"

When you have a team of 20 developers pulling and pushing, the context switching on the CPU is immense. If your server is running on a hypervisor that oversells CPU cycles (common in budget hosting), your SSH handshakes will lag. Latency kills flow.

At CoolVDS, we use Xen virtualization. Unlike OpenVZ containers used by budget hosts, Xen provides strict resource isolation. Your RAM is your RAM. Your swap is your swap. This means when you run a massive build script or a CI integration (maybe using Hudson or CruiseControl), the server doesn't choke.

Furthermore, our network peering at the NIX (Norwegian Internet Exchange) ensures that for any developer sitting in Oslo, Bergen, or Trondheim, the ping is negligible. You get the speed of a LAN with the accessibility of the web.

Next Steps

Subversion had its run, but the future is distributed. By hosting Gitolite on a dedicated CoolVDS instance, you secure your code under Norwegian law, ensure blazing fast I/O performance for your team, and avoid the risks of US-hosted cloud solutions.

Ready to migrate? Deploy a high-performance Ubuntu 10.04 VPS on CoolVDS today. We can have your instance provisioned in under 60 seconds.