Remember the version of your website or application that worked? Just before you tried to add that new feature?
Enter version control. Subversion is an excellent version control system that allows you to roll back to earlier versions of an application and even share the code among different developers.
As already outlined, subversion keeps versions, or 'snapshots', of your website during development. You can then revert to an older version (snapshot) if the path you are taking just isn't working.
Have your website serve a fully functioning version of your application while you happily extend it in the background. When the updated and extended version works, simply have your website serve that snapshot with no hassle for your users.
I highly recommend the Version Control with Subversion book. It's free and on-line. I can't possibly go into as much detail as the book but I'll take you through the basics.
For this article I am using Debian Etch which has version 1.4.2 available. Ubuntu LTS has version 1.3.1 and other distributions have different versions. The latest and greatest version (at the time of writing) is 1.4.5 and is available from source from the subversion website.
Let's get stuck in and install subversion.
sudo aptitude install subversion
That's it for the installation.
Let's create a repository. I'm going to create a folder named 'repository' in my home directory. It can, of course, be named whatever you like and be located wherever you like:
cd ~ mkdir repository
If you have a look inside the repository folder, there is nothing there:
ls repository ...
Let's create the skeleton structure subversion uses to control repositories:
svnadmin create /home/demo/repository
Take a look now:
ls repository/ conf/ dav/ db/ format hooks/ locks/ README.txt
Don't change anything in the repository folder. We'll learn how to add files and projects shortly.
To import 'something' to our subversion repository and begin version control, that 'something' has to exist.
You can import whatever you like (there are a few exceptions, but not many). The most popular use for subversion is to manage projects, from small websites to very large, multi developer systems.
Let's create a temporary folder for our project. We'll call it 'project1'
Now start the project by creating a text file:
I know that project1 is not incredibly realistic; you could have created a rails skeleton or the base of your php website or whatever you wanted, the point is to have something to import to the subversion system.
The recommended layout for a subversion project includes three folders called branches, tags and trunk. I'm not going to go into branches and tags here but concentrate on the 'trunk' of your project. Then name is very apt - think of it as the backbone of your project - this is where the main folders and files are placed.
To import project1, issue the command:
svn import /home/demo/project1/ file:///home/demo/repository/project1/trunk -m "Initial import of project1"
A couple of things to notice include the order of the command (source folder followed by destination) and the '-m' which is short for 'message'.
When you import a version of your project, always add a message describing what the import is. I can assure you that in a week, never mind a month, you will have no idea what version 127 was if you do not include a message.
The output of that command is:
Adding /home/demo/project1/hello.txt Committed revision 1.
Now we delete the original project1 as we don't need it because we've imported it into the version control system.
So, delete the original:
rm -rf project1/
The point of subversion is to control versions of a project.
To do this we need to 'check out' the initial project (this will be version 1). Once done, we can then adjust the project (add files, change files, etc) and at various points 'check in', or commit, any changes we have made. So the next 'commit' would make version 2 of the project and so on.
Assuming you are working on the same machine as your subversion repository (we'll talk about remote manipulation in later articles), create a 'work' directory and check-out version 1 of project1:
mkdir work cd work svn co file:///home/demo/repository/project1/trunk project1
The output is:
A project1/hello.txt Checked out revision 1.
Move into your newly checked-out project1 and have a look:
cd project1 ls ... hello.txt
Look familiar? It's the original project1 we imported a moment ago.
Let's make a small change to project1 and add a folder and file (remember we changed directory so we are now working in the project1 folder):
mkdir goodbye touch goodbye/goodbye.txt
We need to add this change to subversion. This does not commit the change to a new version: it simply tells subversion there is a new file (or folder, etc) that has been added to the project and to include them when the next commit command is given:
svn add goodbye
The output will show that the directory and contents of 'goodbye' have been added:
A goodbye A goodbye/goodbye.txt
To actually commit this momentous change to project1 (thus creating version 2) issue the following:
svn commit -m "Added goodbye section in accordance with milestone 1"
The output shows what is happening:
Adding goodbye Adding goodbye/goodbye.txt Transmitting file data . Committed revision 2.
If you want to delete files or folders from the project, use the same syntax as shown above for 'add' but use 'delete' instead:
svn delete goodbye
The output shows:
D goodbye/goodbye.txt D goodbye
Again, this has not committed the changes. It has simply informed subversion that when there is a 'commit' command, to delete those files and folders.
So to actually commit the recent changes and create a new revision (version):
svn commit -m "Deleted goodbye section"
Deleting goodbye Committed revision 3.
So now we're on version 3 of project1.
There is a great deal more you can do with subversion and one other skill you will probably require early on is how to check-out different versions. We're on version 3 now, but let's say we also want to check out version 2.
Using the same procedure as before and create a directory to work in. This time, when checking out project1, use the '-r' option indicating the version you want to use:
cd ~/work mkdir project1-older svn co -r 2 file:///home/demo/repository/project1/trunk project1-older
This will checkout revision (version) 2 of project1 to the project1-older folder.
Although only an introduction, a fair amount has been covered here. You will get used to these basics very quickly and want more functionality within a very short time.
The next article will concentrate on serving the repository with svnserve so you can check out the project to your local workstation.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License