When you save your work, how saved or safe is it really? How easy is it to overwrite, delete, or mistakenly edit something irrevocably? Ever nuked a project with just one incorrect double-click or click-and-drag? How about multi-developer projects? When many people start using a common set of files, ‘save’ is about as safe as driving without a seatbelt. You’re only one accident away from catastrophe. Ever been blamed for broken code someone else modified (but you couldn’t prove it was them) ?
How easy is it to protect those precious files when things get complicated or rushed? Ever made a folder named bkup, backup, OLD, v2, v3, live, dev, myVersion, etc…? Ever wonder, 6 months later, what said folder contains or if you can delete it? Ever had someone do development on the wrong version of a project entirely? Ever had to deal with having 2 or more versions of a project that both contain independently unique work? Ever just plain lost hours or days of work mysteriously?
If you lack a good (or any) version control setup, then I’ve probably hit a bone with at least one of those questions. If you write software or deal in text-based projects, then let me behoove you to investigate version control solutions. There are a lot of them out there to be sure. Choosing the right one for you can be daunting. In this article I’m going to talk about a program called Subversion (aka SVN) which is very easy to get andinstall. It works on a system of centralized source code control that multiple users can simultaneously work on. Since this is more of a persuasive post, and not a technical how-to article, I’m going to talk about what you can do with subversion rather than its core operation concepts.
To start with we have a new and much more powerful way to save our work. Ctrl-S is still a mainstay, but we can also commit our code to a centralized repository. Doing so creates a new version within the code repository. At any time we can go back and see the entire project as it was for any version. We can see who created each version, what they edited, what they added, what they deleted or moved. We can see when they did it. We can also see version specific comments they’ve left.
Not only do we get this awesomely powerful history, but we can export, view, or rollback the entire project, any folder, or any file to any previous version of such that’s in the repository. We can also, and this is crucially powerful, compare any version of any file to any other version of that file. Suppose programmer Bob broke something over the weekend. Just look at the log and see what files he edited on Saturday and Sunday. Then look at the changes made to those files between now and the last working version. Every change will be shown. Can’t figure out what the problem is? Well, you can always revert the entire project to the Friday version and then reintegrate Bob’s work a little bit at a time.
Things get even more interesting with the branch and merge abilities of subversion. Branching allows developers to create spin-off versions of the code-base that they can work on and commit changes to without affecting the main core of code in the repository. This is much more powerful than just creating a new folder with copied files though. Branches can selectively or wholly absorb changes from the main line of code in order to keep themselves up to date while side-line development continues. Branches can also be merged back into the main line of code once they are done. Subversion remembers which files were branched from which and maintains an ancestry-like relationship for managing these merges.
Never loosing a change and empowering parallel development lines for projects are powerful and advanced tools. Programming time is not cheap and good projects take tons of time. Code is one of the most expensive products a company can produce these days. Why risk costly development resources by only using standard O/S file systems? That’s like asking a designer to work in ms paint rather than photoshop. Worse really when you consider that a lot of version control systems out there are free.
So, I hope I’ve inspired you to get out there and play with possible version control systems. They all take some time to learn and implement, any new technology does, but an ounce of prevention is much better than a late-night overtime weekend cure.
