Console Login
Home / Blog / Development / Escape SVN Hell: Setting Up a Private Git Server for Distributed Teams (2009 Guide)
Development 1 views

Escape SVN Hell: Setting Up a Private Git Server for Distributed Teams (2009 Guide)

@

Private Git Hosting: Total Control for Distributed Teams

If I have to resolve one more svn merge conflict on a Friday night, I might just pull the plug on the rack. Centralized version control was fine when we were all sitting in the same LAN in Fornebu, but now that we have developers in Kyiv and designers in Bergen, Subversion (SVN) is becoming a massive bottleneck.

The solution isn't just "switching to Git." It's about hosting it correctly. Sure, GitHub is making waves, but do you really want your proprietary code sitting on a public cloud in the US? Not to mention the latency. Every `git push` shouldn't give you time to brew coffee.

Here is the battle-tested setup we are rolling out for high-performance, private version control using CoolVDS Linux instances. This setup keeps your data under Norwegian jurisdiction (Datatilsynet compliant) and offers the raw speed your team needs.

Why Latency Kills Productivity

We ran a `traceroute` yesterday. From our Kyiv office to a US-based host, we are looking at 180-220ms. That makes terminal interaction feel like wading through mud.

By hosting on a VPS in Norway (specifically on CoolVDS's backbone), we cut that down to 40ms from Ukraine and <10ms from Oslo. When you are dealing with large binary assets or massive repo histories, that difference is the line between "flow state" and frustration.

Pro Tip: Don't settle for standard SATA drives for your repo server. Git is I/O intensive during garbage collection (`git gc`). We strictly use RAID 10 SAS storage configurations on CoolVDS to ensure disk queues never choke your commits.

The Stack: CentOS 5.3 + SSH

We are using CentOS 5.3 for this. It's rock-solid. We aren't interested in the bleeding edge; we want stability. We will use standard SSH for authentication because it is secure, already installed, and easily managed via `authorized_keys`.

Step 1: Secure the VDS

Before you install anything, lock the door. On a fresh CoolVDS instance, update your system and configure `iptables`.

yum update -y
# Allow SSH, HTTP, and Loopback only
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

Step 2: Install Git Core

CentOS base repositories can be a bit behind. Ensure you have the EPEL repository enabled or compile from source if you need the absolute latest 1.6.x features. For now, `yum` is sufficient.

yum install git

Step 3: Create the Git User

Never run your repositories as root. Create a dedicated user for version control. This isolates your code from the rest of the system.

adduser git
passwd git # Set a strong password

Step 4: Set Up SSH Keys

Password authentication is a security risk and a hassle for automation. Gather the `id_rsa.pub` keys from your developers. On the server:

su - git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

Paste your developers' public keys into that `authorized_keys` file, one per line.

Step 5: Initialize the Bare Repository

A "bare" repository contains no working files, just the version history. This is what you push to. Let's create a repo for `project-alpha`.

cd /home/git
mkdir project-alpha.git
cd project-alpha.git
git --bare init

Client Side: The First Push

Back on your local machine (your workstation in Oslo or Kyiv), you can now add this remote. Since we are using CoolVDS, you'll use the IP or hostname provided in your welcome email.

cd my-project
git init
git add .
git commit -m "Initial commit"
# The magic happens here
git remote add origin git@your-coolvds-ip:project-alpha.git
git push origin master

If you set up the keys correctly, it will push immediately. No passwords, no waiting.

Why Not Just Use Shared Hosting?

I've seen people try to host Git on standard shared hosting accounts via WebDAV. Don't do it.

Feature Shared Hosting CoolVDS (Virtual Dedicated)
RAM Access Shared/Choked Guaranteed/Dedicated
Protocol Slow HTTP/WebDAV Fast SSH
Data Privacy Risky Strict Norwegian Standards

Shared hosting creates "noisy neighbor" issues. If another site on the server gets hit with traffic, your `git pull` times out. On a dedicated resource platform like CoolVDS, your CPU cycles are yours alone. This is critical when your CI/CD scripts start running automated builds.

Final Thoughts

Moving from SVN to Git requires a shift in mindset, but hosting it shouldn't be a headache. By building your own Git server on a robust Linux VDS, you save on licensing fees, keep your data within the European Economic Area, and ensure your team isn't waiting on trans-Atlantic latency.

Ready to ditch Subversion? Spin up a CentOS 5 instance on CoolVDS today. With our 15k RPM SAS storage and gigabit uplinks, your commits will finish before you can even lift your fingers off the keyboard.

/// TAGS

/// RELATED POSTS

Building Blazing Fast REST APIs with PHP 5.4: A DevOps Survival Guide

SOAP is dead. Mobile is eating the world. Learn how to architect low-latency JSON APIs using PHP-FPM...

Read More →

Scaling Real-Time Apps: Node.js v0.6 Production Guide on SSD VPS

Is Apache killing your concurrency? We dive into deploying Node.js 0.6 on Ubuntu 12.04. Learn to han...

Read More →

Stop Coding on Localhost: Architecting a Mirror-Grade Dev Environment on VDS

Local environments lie. Learn how to build a production-grade development sandbox using KVM, Nginx, ...

Read More →

RESTful API Design in 2009: A Guide for Norwegian IT Professionals

As Web 2.0 matures, Norwegian businesses are moving from SOAP to REST. Learn the best practices for ...

Read More →
← Back to All Posts