This article is the second in a series of guides about my experiences using Subversion (svn) for Web Development. These are the articles in the series:
1. A Desktop-Laptop Solution for Web Developers – Using Subversion to Co-Exist (this article)
2. What is Subversion and How Does it Help in the Web Design and Development Process? (this article)
3. A Subversion Workflow for Web Developers and Web Development
4. A Review of SmartSVN – a GUI Subversion client for Windows
5. A Quick Review of Online Options for Hosted Subversion for Web Developers
6. A Brief Review of Assembla, an Online Subversion Hosting Company.
There’s a ton of great information about the specifics of Subversion and how to use it, so I’m not going to go through all of that here. There’ an excellent free book online, “Version Control with Subversion” which I strongly recommend that you read (at least the beginning few chapters). Rather, here I will discuss the core concepts of subversion as they relate, in my workflow, to web development.
Synchronization and Version Control
The two main ideas to understand when using subversion are the concepts of 1) keeping your files in sync among multiple machines and developers (if needed) 2) at the same time maintaining a log of revisions — with the ability to roll back those changes.
Consistent Copies
The first main concept behind using subversion (svn) is that the main files for your project – in our case a website – are stored on a central server called a repository. When you want to work on the website, you connect to this central server and you synchronize your local copy with the copy that’s on the server. SVN actualyl doesn’t use the word synchronization — if it’s your first time working on the project on the specific machine, you first download (check-out) a copy of the site from the repository (called a working copy) and you then make your changes. If you’ve already worked on the project on the chosen machine, you would head to the repository and update your copy — which is the method of making sure that your working copy is current (in sync) with the copy that’s in the repository.
Version Control
The second major advantage is that not only to you have an easy way to work on updated code no matter what development machine you use, but version-control is built in. In my own personal version control methodology, which I’ve been using for years, I saved multiple version of my work in progress and each time saved an exact duplicate of the entire site. Subversion, in contrast, logs the changes that you have made in each version — so while it does not keep a physical copy of every version that you have, a record of your changes is kept so that you can revert back to any revision at any time. This is the concept that took the most time for me to get used to — I like having hard copies of everything — but the more I use subversion (backing up my repository, of course) I realize that these extra backups aren’t necessary. You can read this article if you want to see how I used to manage my web design version control.
One of the reasons that I chose to work with SVN is because I develop a lot on my laptop, but wanted to also harness the power of my desktop machine. I thus work on my latptop and I upload (commit) the changes to the repository. When I’m on my desktop machine later, I can easily run the update command to make sure that my desktop copy is current with the copy I just finished working on on my laptop.
More Subversion Vocabulary: Trunk, Branch, Tag
Finally let’s touch upon a few more subversion concepts/vocabulary items. These items are trunk, tag, and branch. The trunk is generally defined as the main line of development, whereas a tag is used to take a snapshot in time of the trunk. Lastly, a branch is used when you want to go off in a different direction for a while, but at the same time keeping the main development line (trunk) intact. As a simple example, if you are working on a website and you are ready to code the contact form, and you’ve coded it a certain way first, but decide now that you want to try a different script to implement the form, you can use a branch. The thought is that your main development (i.e. your main, stable code) stays untouched in the trunk, and you can work on this new contact form coding method in a branch without altering your trunk. If you then decided that you are happy with this new contact form code that you’ve written in your branch, you can now merge this branch into the main trunk. Note that merging is a straightforward process that does need a degree of care and planning. You don’t want to merge code back in that will break your original code, so it pays to do a little reading (and practice) with merging before you perform a merge on a real-life client project.
Note that trunk, tags, and branches are really just nomenclature — these folders as you will learn, don’t exist in any special format — but it’s how you are managing them that make the difference. Thus it’s by convention that we keep our main line of code in the trunk, and the side or other development pieces in the trunk. You could just as easily call them the body and the arm, but convention is trunk and branch. Note also that there’s nothing special about a tag other than the fact that we are calling it a tag and that, by convention, tags are not touched. As a tag is designed to be a snapshot in time of your trunk, it make no sense to copy and change your established tag. And while if you wanted to you could make changes to a tag, by convention, it doesn’t make sense, as the whole idea behind a tag is to have a copy of the trunk at a certain point in time that you will not be changing — thus making a large rollback possible. Obviously you could always go back to previous versions using the trunk, but it’s just more practical if you want to make a major rollback to have the ability to use a tag. Having tags also allows you to keep frequent “backup” copies of your work in progress.
In the next article, #3 in the series, I will discuss my Subversion Workflow for Web Developers and Web Development.