Let's suppose that I just started working at a small firm with 10 employees, and we're working on a programming project. Bob and I became fast friends and we get along great. But Bob and I have also been assigned to work on the same piece of code in the same source file. This obviously creates a problem. Just last week, Bob made the mistake of working on the file when I was also working on it, and the 2 hours I spent writing that nifty function was lost forever when Bob overwrote my changes with his. Now Bob e-mails me whenever he starts to work on the file and when he stops working on it so we don't come across this problem again. However, Bob sent me an e-mail today telling me he's going to work on the file, and it's been 4 hours since then...oh look, here comes Bob now. He just told me that he forgot to e-mail me 3 hours ago telling me he was done with the file. What did I do with my 4 hours? Twiddle my thumbs, re-arrange my desktop, change my wallpaper, and take a quick nap. Now I get to work on the file, and Bob gets to take a paid mini-vacation thanks to me.
As you can see, this is a very big problem. What if Bob and I need to work on the same file, but on different parts of it that don't overlap? What happens if Bob accidentally overwrites my changes? Is there any way of handling overlaps when they do happen? This is exactly what configuration management aims to control automatically so that the programmers can do their job rather than send out "are you done yet?" e-mails. In this case we will be using Subversion, abbreviated as SVN, to get the job done.
Subversion? Sounds scary!
A secret agent, clad in an expensive tuxedo and armed with nothing more than a small pistol, somehow manages to infiltrate a top secret enemy base and subvert the computers that are aiming nuclear warheads at a friendly country. Cue the explosions and the dashing escape, and complete the mission successfully while getting the girl to boot. Fortunately (or maybe unfortunately), this is not what happens when we use Subversion to maintain our source code. So what is Subversion? At its core, it's nothing more than a file server that allows people to upload and download files. However, it's the additional features that differentiates Subversion from other file servers. It does three things that the others don't do:
1. Revision history - SVN tracks all changes made on files so that it's possible to get any previous versions of the file. It's like a little time machine that allows you to go back to any point in the file's lifetime.
2. File edit merging - SVN allows multiple users to be working on the same file at the same time. Users 'check out' a local copy of the file, make their edits, and then upload them to the server. If two people check out a file at the same time but one of them uploads it first, the second person won't overwrite the first person's changes when he uploads his copy; the two files will be merged together with both of the edits - unless there's a overlap.
3. Merge overlap handling - if two people try to upload a file and there is an overlap in the edits, SVN will notify the user and let him handle it. This way one user cannot overwrite another user's work without his knowledge. So as we can see, SVN solves the issues mentioned earlier quite well, allowing more than one person to work on a file at once, merging their changes, and dealing with overlaps. Now that we know what SVN can do, we can move on to the practical part - actually using SVN to manage a project.
Step 1. Install an SVN client
Our assignment for this week begins off with us installing an SVN client, TortoiseSVN in this case. Don't let the name fool you, TortoiseSVN is not only free, but quite powerful. It integrates into the shell, allowing you to right click on a folder and instantly turn it into a SVN-managed folder. I ran into no problems installing and running this SVN client and I highly recommend it if you don't already have a favorite SVN client that you use.
TortoiseSVN right-click shell menuStep 2. Modify an existing Google project
To start off simple, we're going to take an existing Google project, modify it, and then upload it to the SVN server. A nice, simple project has been provided for us by our professor, the same stack project we've worked on before. I created a folder and 'checked out' all the project files into that folder, then modified a Javadoc comment slightly and then uploaded my changes to the SVN server. The process is quite simple, and the only cumbersome part was having to use the command-line-only Ant to verify the project before and after the modifications to make sure it wasn't broken to begin with and it isn't broken after the changes were made.
SVN changelog for stack-johnson projectStep 3. Create a new Google Hosting Project
Now that we've modified an existing project and have learned how to use SVN, we're going to create our own project and upload it to Google Project Hosting so that it's SVN-managed. After creating the project page on Google Code, all we need to do is create a folder on our computer, use SVN to check out the files from the SVN server (which should contain only 3 empty folders), and then add in our source code and commit it to the server. The process is pretty straightforward, but remember to check the project settings to see which directory SVN checks out by default. Mine was set to the trunk directory, and when I uploaded my files, I put them in a folder called trunk, resulting in all my files being put into the trunk/trunk folder. Also, it's very easy to forget to add a description of what was changed, and after you finish committing it I don't think there's any way you can modify it, so don't forget to add in a description of what you modified each time.
SVN changelog for my own stack project, notice how I forgot the description the first two timesHurray for SVN!
Although the exercises in this post don't really show off the true usefulness of SVN, it's easy to see how this tool is crucial when there are multiple people working on one project. Even when there's only one developer, it can be used to keep track of file changes, which might come in especially handy when a big part of the code is modified and the entire program breaks but there are no backups of the older versions, a situation I've been in before. SVN is much more than just a simple file server, so take advantage of all the features that it offers!
No comments:
Post a Comment