Are you a web developer working either solo, or in small team? Are you using version or source control of your code? If not, please stop, save your work and read this before continuing.
Programmers and designers like to create, this is what makes their working day exciting. And doing this in a small team or on your own means issues such as version control are only the problem of large groups. They are most likely keeping daily backups for the last week or 2, and prior to that (maybe) monthly backups.
Having worked in a number of large and small organisations, with and without version control, I would like to give a few reasons why a version control system (VCS) is important for you too.
History is important
Understanding and solving the problem in front of us is enough of a challenge without trying to remember the history of a file that has been changed 10 times in the last 2 years. A version control system will easily output a log of changes for a file(s), times and dates, who made the change, a line by line file difference, and the comment entered after the change. Of course how relevant this information will be, is influenced by the person(s) who made the previous changes. No system can enforce the quality of commit comment, or the relevance together of committed files, but it is still a better situation than a file based, point in time backup with no incremental or related change information.
Trial and error
Not all ideas work, and not all code changes make a better application. So if my brainwave turns out to be a dud, a revert back to a previous stable point is easy, and no need to worry about putting aside a clean copy of code, to copy back over. If the new idea requires large changes, then a version control system will handle a stable version and 1 or more development branches. This new development version may become the main trunk or a branch that is quickly cut off.
In the day changes
Some days are just productive. The changes are flying (and working), and are being committed to the master repository as you go. Wham the hard drive dies on your work PC. If all your changes since the last backup are on the local PC only, then a good day is wasted. However if the version control repository is on another computer (as it should be), all your work up to the last commit is there.
A little structure is good
Breaking a problem into smaller chunks is good for solving issues. A VCS will not force you to commit your code changes in small atomic parcels, but it will handle it very well. With any luck this will improve your code and reduce bugs.
Not just code
Until now I have just mentioned code. However any computer based file that could be modified over time is a candidate for control. This could be project documents, graphic files, build scripts or boring old code files. Even files that are unlikely to change, could be stored securely with a date and short message. This is why I use the more generic term version control over the narrower code or source control.
Not expensive to setup
A spare PC with reliable hard disks and some degree of disk failure capability. No fancy video cards or even monitors required. Many very reliable VCS systems come free with Linux distributions or other OS. To name but a few in no order of preference: Subversion (SVN), CVS, Git, Mercurial. Note: Git and Mercurial are better for larger distributed development teams.
Many IDEs have integrated version control actions. This makes it easy to make your changes and commit them to a repository for within 1 application.
File manager integration
SVN and CVS actions are possible from the Windows explorer using TortoiseSVN and TortoiseCVS. The Nautilus file manager in GNOME can be used to perform SVN actions.
I was hoping for more of a how to set it up and effectively use SVN or one of the other source control systems.
An SVN article will be coming in the next week or so.
Another nice feature of version control is bug finding by bisecting history trying to find commit (change) which introduced the bug in question (called also ‘diff debugging’).