The SVN Server

Nowadays I take it for granted that everything is in git. Even my Uni dissertation was stored in a git repo. But this is a story of the first time I was exposed to source control, back when SVN was the top dog, and someone had a genius idea of how to set it up on a server.

SVN itself wasn’t too bad. Sure it made branching and merging nigh on impossible but it was simple and reliable as long as the central repository was available. For the type of site we were making at the time it was “good enough”.

Anyhow, our hosting provider offered to set up a neat solution for us (this was before I learnt to take charge of the command line). Our host would put the SVN repo on the web server and every time you pushed code to it, it would be live automatically! No more icky FTP.

Yep. My first experience with a VCS was committing code to a central server and having it go live straight away. There was no concept of a staging environment, just whatever was in the repo was the site. And that’s not to mention the problem of assets. If there was a writable directory on the server you better hope there wasn’t a conflict otherwise your changes would be rejected and the server locked.

But there was something else. Something that started off small, so innocuous you didn’t notice it, until a new dev joined and you had that sinking feeling as you realised you had to rationalise it to them.

Every single site was in the same SVN repository.

All of them.

The directory name was the domain name and everything lived inside of it. If you made the mistake (and everyone did at least once) of pulling down the entire repository instead of taking just the directory you needed you were in for a very long wait. The tree just grew and grew. Checking in videos and other large assets just exacerbated the problem (pigs-in-the-repo as they euphemistically became known).

Eventually we reached a tipping point. We needed to stage changes, we needed individual control over sites and we just couldn’t call ourselves developers if we continued with the insanity we found ourselves in. So not long after starting, we broke the monolithic repository up and configured separate deployments for each. Now we could push to a staging site and only then, after all changes had been QAd, would we go live. Eventually we jumped from svn to git as well, a process that was only accomplished by the act of any new development following the rule of “if it’s in svn, you have to migrate it first”, but we got there.

Nowadays we have a whole host of systems and no longer is it just code that’s revisioned. Database schemes and even infrastructure templates are all stored under source control. Branches and pull requests mean multiple teams can be working on features and we can all push them out as needed.

All of which isn’t to say our current set-up is perfect, we still have manual staging environments for instance, but it’s shown us one thing over the years; we’re not afraid to change how we work just because it’s difficult.