Stop Screaming at Subversion: It’s Time for Git

If I hear one more developer complain about a broken build because of a failed SVN merge, I’m going to pull the plug on the server myself. It is 2009. We have better options.

The centralized version control model is dying. Linus Torvalds proved it with the Linux kernel, and smart development teams are following suit. Distributed Version Control Systems (DVCS) like Git are not just a trend; they are a necessity for any team that cares about code integrity and sanity. especially if you are managing distributed teams across Norway and Eastern Europe.

But here is the problem: third-party hosting like GitHub is great for open source, but do you really want your proprietary commercial code sitting on a US server you don't control? Not with the current concerns regarding data privacy and corporate espionage.

Today, we are going to build a fortress. We will set up a private, secure Git server on a CoolVDS Linux VPS running CentOS 5.3. We will use gitosis for access control, allowing us to manage permissions without giving every junior developer a shell account.

Why Latency and Disk I/O Matter for Git

Git is fast, but it is also I/O intensive. When you run git gc or clone a massive repository, the server disk gets hammered. Most budget hosting providers oversell their storage, putting you on crowded disks where your I/O wait times skyrocket. You type git push and wait ten seconds. That breaks flow.

This is why serious sysadmins choose CoolVDS. We don't use cheap SATA drives for our production nodes. We utilize enterprise-grade SAS 15k RPM drives in RAID-10 arrays. This provides the redundancy you need and the read/write speeds that keep your commits instant. Furthermore, hosting in Norway means your data is protected by the strict Personopplysningsloven (Personal Data Act), keeping the Datatilsynet happy and your IP safe.

The Setup: CentOS 5.3 + Git + Gitosis

Let's assume you have a fresh CoolVDS instance. I prefer CentOS 5 for its stability, but these commands work on RHEL as well.

1. Install Dependencies

First, we need the EPEL (Extra Packages for Enterprise Linux) repository because the stock CentOS repos are—let's be polite—conservative. We also need Python setup tools for Gitosis.

[root@coolvds ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
[root@coolvds ~]# yum update
[root@coolvds ~]# yum install git python-setuptools

2. Create the Git User

Never run services as root. We create a dedicated user that will own the repositories. This is basic security hygiene.

[root@coolvds ~]# useradd -m -d /home/git -s /bin/sh git
[root@coolvds ~]# passwd -l git

3. Install Gitosis

Gitosis allows you to manage access using a single SSH user (git), differentiating developers by their public keys. It is far cleaner than managing generic UNIX permissions.

[root@coolvds ~]# cd /tmp
[root@coolvds ~]# git clone git://eagain.net/gitosis.git
[root@coolvds ~]# cd gitosis
[root@coolvds ~]# python setup.py install

4. Initialize the Repository

Upload your local public key (id_rsa.pub) to the server's /tmp directory. This key will belong to the administrator (you).

[root@coolvds ~]# sudo -H -u git gitosis-init < /tmp/id_rsa.pub
Initialized empty Git repository in /home/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/

Now, make sure the permissions are locked down.

[root@coolvds ~]# chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Managing Your Team

Here is the beauty of this setup: you don't need to log into the server anymore. You manage the server configuration via Git itself.

On your local workstation:

my-laptop$ git clone git@your-coolvds-ip:gitosis-admin.git
my-laptop$ cd gitosis-admin

You will see a gitosis.conf file and a keydir directory. To add a new developer, drop their public key into keydir and add them to the config file:

[group mobile-team]
members = jens@oslo ivan@kyiv
writable = mobile-app-ios

Commit and push. The server updates its permissions instantly. No sudo required.

Pro Tip: If your development team is split between Oslo and Kyiv, network jitter can corrupt large pushes. Configure your SSH KeepAlive settings in /etc/ssh/sshd_config on the server: ClientAliveInterval 60. This prevents the pipe from breaking during massive initial clones.

The Hardware Reality Check

Running a centralized Git server puts significant load on your virtualization platform. If you are on a budget provider using OpenVZ with oversold RAM, you might see the dreaded "Out of memory" error when Git tries to repack objects.

At CoolVDS, we use Xen virtualization. This means the RAM you buy is physically allocated to your kernel. It cannot be stolen by a neighbor running a heavy MySQL query. When your team in Ukraine pushes a 500MB update, the server handles it without sweating, ensuring your Oslo team can pull it down with low latency immediately.

Don't let cheap hosting bottleneck your development cycle. Your code is your business's most valuable asset. Treat it that way.

Ready to ditch SVN? Deploy a Xen VPS on CoolVDS today and get your Git server live in under 10 minutes.