23-Oct-2009
Many developers and document controllers associate Version Control with teams of people working together, using the tool
to make sure that the documents they are working on are managed properly, and that changes to these documents are properly
controlled.
True, but the majority of the benefits that multiple users get from a Version Control system also apply to the developer
working for themselves. Yes, all the following points can be handled in a myriad of different ways but, from the feedback we
have, it boils down to the following features:
Undo/Rollback/Redo: the major feature of any Version Control system is the maintenance of all previous versions of all
files in your projects. That is, of course, dependent on how regularly you check your files in. With good IDE integration and
regular checkins, there is no excuse for lost code or document changes. You can work on your files without the worry of losing
anything more than your last checkin, and be safe in the knowledge that if you need to you can always fully or partially revert
back to any previous version.
Differences: unsure what changes you made to the most recent copy of your file? Need to go back even
further to find out what changes you introduced between versions? The ability to view changes between versions of your files
can be a lifesaver when it comes to maintaining code and fixing bugs.
Backup: you know that there is a centralised, Version Controlled, copy of all your important files.
Should anything happen to your development machine, you have the ability to restore everything from within the relevant IDE
or through the GUI client.
Baselining/Experimentation: you've reached an important milestone in development and everything works,
but you've just had an idea that might improve feature X. You could simply make a copy of everything as it is and continue
working. Or, you could check everything in and apply a Version Label. With the second option, you have a way of reverting
back to your original files (as you can with the first option), but you also have the option of easily finding out what
files you modified, what the changes were, and can retrospectively apply/undo the changes that work.
History: or 'Why did I do that?'. When modifying files it is often prudent to assign notes to document
as to why a change was made. This can often be done in the code or document itself, but not all document formats support
this without changing the deliverables. Using a Version Control tool allows the modifiers of the code/document to specify
why a particular change was made. In addition, if using an integrated issue tracking tool, it can be possible to associate
code/document changes with a particular bug or issue.
Any File: a common misconception about Version Control tools is that they are aimed at source code and
developers. Not true. The vast majority of Version Control tools can handle almost any file of almost any type and any size.
Central: the majority of Version Control tools either subscribe to a central or distributed repository
model. Either way, your documents can be available at any time and at any location.
All the benefits above, and more, apply as much to individuals as they do to teams. The ability to track changes, modify code
with the knowledge you can always get back to where you were, the benefit of knowing why you made a change and the ability to
access the latest version of your source from anywhere, are quite compelling.
From our experience, people who start using Version Control couldn't subsequently contemplate working without it.
It's free for solo developers in most cases (including Team Coherence), so why not give it a try and see how it can
help you manage the messy process of source and document control.