Simple Version Control with SVN

Git is better, but SVN is fun too

Introduction

If you made it here, I'll assume that you want to use some sort of version control system to keep track of individual versions or changes to your website. SVN (abbreviation of Subversion) is a good, simple version control system, especially for websites of which there is only one live, production version. The goal of this tutorial is to set up a development website and a production website. As an example, I'll assume the following setup for this tutorial:
  • Development subdomain: devel.techinternets.com
  • Development web-root: /www/devel.techinternets.com/public_html
  • Production subdomain: www.techinternets.com
  • Production web-root: /www/www.techinternets.com/public_html
  • Linux username: adam

1) Installation

First, check to see that the SVN server is already on your machine. If the command does not return a path to you, you must install it. Below are apt-get and yum examples for how to get it. If these installation method methods do not apply to you, a simple search should return steps relevant to your situation.

2) Create a repository

In our setup, there are three important directories:
  1. Production version of the website - what the users see
  2. Development version of the website - where you do work
  3. Repository location - where the version archive is stored
The repository is the location that will hold all the versions and comments. This should be in some non-web-accessible location. I prefer to put it in /srv/svn_repos/, but you could stick it anywhere. The last part of the path is the name of the repo; it can be anything.
You must now create a SVN user. Open the config file (/srv/svn_repos/techinternets/conf/svnserve.conf) and make sure the following lines are set: Then edit the password file (/srv/svn_repos/techinternets/conf/passwd):

3) Set up the repository

You will want to create a folder in your repository where you will put your files. It is easiest to use the same name as the directory where you currently web files from. If you already have files, you could now import them into your repo:

4) Start the svn server

On RedHat Linux, the easiest way to run the server is with init.d or service

5) Edit files in your workspace

You need to go to your development directory and then check out the repository with the svn co command. The ? next to a filename means that it must be added to the repo. The A next to it, means that it will be added when you commit a new version. When you commit, the -m tag allows you to add some meaningful message so that you will know what version to grab later, if you ever need to step back through code versions. The last svn status command has no output which means that there are no pending operations and that your working directory matches the repository.

6) Put a version in production

Now that we've committed a change, let's put it onto the production website: Now the latest (and fully tested) version is available for everyone to see. If you add an apache virtual host for the development website, you are able to build and test everything there before doing a push back to production.
It is a good idea to write a little script that runs the svn co command. You would just run the script every time that you have committed a version that is ready to be pushed live.

7) Rest easy

knowing that you never have to rush to fix a major mistake before half of your visitors see it. Leave in on devel until the morning!

What is branching/tagging?

SVN really doesn't have "tagging" like CVS or GIT. Instead a branch (tag) is a copy of your code that can act independently from each other. For example, if you wrote ms office version 5, you would branch off of that code for version 6. This branch allows you to continue working on version 5 without worrying about anything you added for 6, and vice-versa. They would appear as seperate folders in your repository: I had you set up your public_html folder as a branch so that in the future, you will be able to include other non-web files folders in your repo. For example you might have the following 3 branches for your website repo.

There are other reasons to branch, but I'll leave it to your imagination or a Google search to figure out why or how.

Possible Problems

Error with no way to handle it

Error: When SVN has an error, it likes to present it to you in the form of a text file. If you have no default text editor set up, then it can't open the error. A good solution is to edit your ~/.bashrc file to include a default editor. If you wanted vim as your default, you would add this line: vim could be replaced with any other executable editor (emacs, nano, pico, ...). After editing your bashrc file, you will not see the changes until you run:

User cannot access a lock file (or other files in the repo)

Error: The easiest way to get around this is to add your user to a new group and give those files group write privileges. For example, I would create the techinternets_svn group and add adam to it. Then I would allow that group to write to those files:

If there are other problems you encounter, let me know and I might include them here in order to help others with the same situation.

About

I created this tutorial on CentOS linux. If you have problems on other systems, let me know and I may be able to help.

Resources used:

You may find the following websites useful. I definitely found them useful while writing this tutorial!
💰Money Zone💰
Want to help pay for coffee, beer, or hosting?
Buy Adam a coffee Buy Adam a coffee