I’ve seen advice from at least one agile guru that if you believe in a good practice but your team members aren’t using it, you might want to go ahead and do it yourself anyway. You will be more productive in the long run, and you might inspire others to do the same. Normally this is applied to testing, but I’m going to apply it to source control.
Here is an example drawn from my current experience. You’ve (well, I have…) been given some code in a zip file, and you’ve been asked to fix/enhance/productionise it. It’s not a big project, maybe a man-week or two of work, and you are on your own. And it’s not under source control anywhere.
Source control has benefits for even a even a one-man project: backups, tracking changes, backing out of changes, and generally more freedom to muck with the code knowing that you have a safety net in case it stops working. As the man said “Source control is like flossing - you don't have to floss all your teeth - just the ones you want to keep." So in this case you can do without versioning, or you can try to get it only a source control server somewhere.
But there is a simpler way. I’m going to show you just how ridiculously easy it is to get your project under “single-serving” source control. You won’t need anyone’s help. You won’t need to pay for a software licence. If your laptop explodes you won’t automatically have a backup on another machine; but I think it’s well worth the five minutes that you’ll spend setting it up.
The repository will take up a few Mb of space, but hard drive space is beyond cheap these days. And the extra time spent committing files and reviewing the changes that you’ve made? That was always a productive use of time anyway – having the differences highlighted for review before committing is almost as good as an extra pair of eyes on the code.
The steps are as follows:
1) Firstly, if you don’t already have it, install the latest version of TortoiseSVN from http://tortoisesvn.tigris.org/.
2) Decide where to keep the version repository. If you have two hard drives, by all means keep the repository on a different hard drive to the working copy, but my laptop doesn’t have that. So I decided on “C:\SvnRoot\MyProjectName”. I’m hoping to have “C:\SvnRoot\MyNextProject” and so on later.
3) Go to the repository directory in file explorer, right-click in it, and select “TortoiseSVN|create repository here”. Make it of type “Native file system”. Now you have an empty repository, and you can store some files in it.
4) Make an “import directory” ready to add to your repository: take a copy of the code that you are working on, and delete the files that you don’t want under version control – e.g. the .dll, .exe, .cache .suo and .pdb files. The directories named bin and obj can also go.
5) Right-click your import directory in file explorer, select “TortoiseSVN|Import”. For the URL, enter ” file:///C:/SvnRoot/ MyProjectName” or whatever your repository path from step 2 is. Press OK and all the files will be added to the repository.
6) Make a new “checkout directory” for working with the code under source control. Mine is “C:\ MyProjectName \Checkout “. Go there in explorer, and right-click. Select “SVN checkout”. The URL to get files from is as above: ” file:///C:/SvnRoot/ MyProjectName”.
The rest is housekeeping:
a. Check that the projects under the checkout directory can compile. If they can’t, locate the missing files in the original version, put them in the right place in the checkout directory, and add them to Subervsion. Remember to commit after adding.
b. Look through the checkout for files that shouldn’t be under source control – i.e. any output or extraneous files that you missed. Delete them and commit.
c. Delete the import directory – it’s not of any use anymore.
d. Cary on working. Remember to check in regularly, whenever you get to a natural break in your code – nobody is depending on you except you. I’m not going to tell you now how to use Subversion or Source Control in general: there’s a lot to say, but it’s not the point of this article.
At any stage of this import process you can back out, delete the files that you have created, and start over or give up. If all goes well, you can have it all up and running in under 5 minutes. Well worth it!
Disclaimer: I’m not setting out to persuade you that Subversion is the only version control system that is worth using – there are several others that are also good, though I don’t think any of them address this particular case quite as easily. I’d be interested to hear otherwise.
I’m presenting Subversion as a pragmatic solution to a small problem, though it is also a powerful system that scales up to much larger problems. Now that there is this version control system that is powerful, quick, easy and free of cost, there’s no reason at all to avoid all version control, even for small projects.