Stop Letting Subversion Ruin Your Weekends
If I have to resolve one more "Tree Conflict" in Subversion (SVN) while trying to merge a feature branch, I am going to pull the power cord on the rack myself. It is 2010. Distributed Version Control Systems (DVCS) are not just a fad for Ruby on Rails hipsters anymore. Linus Torvalds gave us Git years ago, yet too many enterprise teams in Oslo are still clinging to centralized version control like it's 1999.
The problem isn't the technology; it's the hosting. GitHub is fantastic for open source, but have you seen the pricing for private repositories? If you have a team of twenty developers, the costs spiral out of control. Furthermore, do you really want your proprietary code sitting on servers subject to the US Patriot Act? I didn't think so.
Today, we are going to build a fortress. A private, secure, and incredibly fast Git server using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). We will host this on a CoolVDS Xen instance because we need guaranteed RAM, not that "burstable" nonsense OpenVZ providers try to sell you.
Why Gitolite?
You might have heard of gitosis. Forget it. It's practically abandonware. Gitolite is the new standard for managing Git access control. It allows you to define permissions down to the branch level using a single configuration file committed to... wait for it... a Git repository.
It creates a seamless workflow where your infrastructure is code. You push a change to gitolite-admin, and the server reconfigures itself instantly. No logging into SSH to add users. It is elegant. It is efficient.
The Hardware: Latency Kills Productivity
Before we touch the terminal, let's talk about iron. Git is fast, but it is I/O intensive during cloning and garbage collection. If you run this on a cheap shared host with oversold hard drives, your git status will hang.
For a team based in Norway, latency to the server is critical. Every millisecond of delay adds up when you are pushing huge changesets. This is why we deploy on CoolVDS. Their datacenter is peered directly at NIX (Norwegian Internet Exchange) in Oslo. Pinging a US server takes 100ms+. Pinging a CoolVDS instance from downtown Oslo takes 2ms. That difference changes how your team feels about committing code.
Prerequisites
- A fresh CoolVDS VPS running Ubuntu 10.04 LTS.
- Root access.
- Your local public SSH key (
~/.ssh/id_rsa.pub).
Step 1: System Prep and User Creation
Log into your VPS. First, let's make sure Lucid Lynx is up to date. Security patches matter.
apt-get update && apt-get upgrade -y
apt-get install git-core
Now, create a dedicated user for Git. Do not run this as root. If you run services as root, you deserve to get hacked.
adduser
--system
--shell /bin/bash
--gecos 'git version control'
--group
--disabled-password
--home /home/git
git
Step 2: Installing Gitolite
Switch to the git user. We are going to install Gitolite from the source because the repository packages are often outdated.
su - git
mkdir -p ~/bin
git clone git://github.com/sitaramc/gitolite
gitolite/src/gl-system-install
sh -c "PATH=/home/git/bin:$PATH; gl-setup -q /tmp/your_admin_key.pub"
Note: You need to upload your local workstation's public key to /tmp/your_admin_key.pub on the server before running that last command.
Pro Tip: CoolVDS instances use Xen virtualization. This means the swap space is actual disk partition, not a fake container file. If you have a massive repo (gigabytes of assets) and run out of RAM during a repack, the kernel OOM killer won't immediately murder your process. It handles memory pressure like a real server.
Step 3: configuring Access Control
Here is the magic. You don't configure the server on the server anymore. Log out. Go back to your local workstation.
Clone the admin repository:
git clone git@your-vps-ip:gitolite-admin
Inside, you will find two folders: conf and keydir.
- keydir: Drop your developers' public keys here (e.g.,
jens.pub,kari.pub). - conf/gitolite.conf: This is where you define who can do what.
Edit the config file to add a new project:
repo secret-project
RW+ = jens
R = kari
Commit and push:
git add .
git commit -m "Added secret-project and Kari"
git push origin master
Done. The repository secret-project now exists on the server. Jens can write and force push (RW+), Kari can only read (R). No ticket to IT support required.
Data Sovereignty and Compliance
In Norway, we take the Personopplysningsloven (Personal Data Act) seriously. The Datatilsynet (Data Protection Authority) has been very clear about the risks of third-party processors. By hosting your code on a CoolVDS server in Oslo, you maintain physical and legal control over your intellectual property.
| Feature | GitHub (Private) | CoolVDS Self-Hosted |
|---|---|---|
| Cost | $$$ Per User | Flat Rate (Cheap) |
| Location | USA | Norway (Oslo) |
| Disk I/O | Shared/Unknown | Dedicated RAID-10 SAS |
| Control | Theirs | Yours |
The Backup Strategy
A Git server without backups is just a temporary storage location. Since everything is a file, backing up is trivial. Use rsync to pull the /home/git/repositories folder to a backup server nightly. Or better yet, use the CoolVDS snapshot feature in the customer portal before running major updates.
Conclusion
Setting up a private Git server on Ubuntu 10.04 isn't just about saving money. It's about performance and control. You get sub-10ms latency for your Norwegian team, you keep the Datatilsynet happy, and you escape the tyranny of SVN merge conflicts.
Don't settle for sluggish pushes over the Atlantic. Spin up a CoolVDS instance today and experience what local, high-performance hosting actually feels like.