It amazes me that for the first 20 years of my 31-year programming career, I only used a Version Control Systems (VCS) once: a two year job in aerospace where they used a mainframe package called CMS. Apart from an editor/compiler, a VCS is the one piece of software that all development teams, from single person outfits to those with thousands of developers, should definitely use. A VCS lets you:

• Manage multiple versions of source code (and with some products) binary files such as images, video, sound files, etc.
• Compare the differences between older and newer versions of files and switch to earlier versions.
• Use labels and branches to manage different versions.
• Merge changes between files or folders of files.

Before VCS's were used commonly, it was quite possible to lose files and lose changes. You could end up with multiple backups (by using archiving utilities like PkZip or WinZip) and be unsure of a file's latest version. It required self-discipline not to misplace files.

Things Get Better

However as soon as networking became commonplace, server-based solutions like the open source CVS came into everyday use. Microsoft and other firms also sold commercial VCS systems, such as Perforce, which became popular in large enterprises. The older, centralized VCS was on a central server. On that server, each project contained the files, sources and binaries. Permissioned users could get read-only copies of all files on their desktop PC. If they wanted to make changes, they would have to explicitly check the files out. VCS worked like this until about five years ago when it was supplanted by another open source project called Subversion. Subversion integrated neatly into Windows, allowing users to use Windows Explorer to view files, check them out and check them back in. It actually made using a VCS bearable. Before that, I once had to manually check in 60 files from the command line. Over the last five years a new breed of VCS, the Distributed VCS (DVCS), has become popular. These include Git (written by Linus Torvalds of Linux fame), Mercurial, Bazaar and others. A DVCS doesn't use a central repository. Instead, each individual team member has their own repository copy and the DVCS provides tools to merge and update them safely. HgInit is a really nice tutorial and introduction to using Mercurial. If you're a developer, artist, website designer or even a writer and you aren't using a VCS, you owe it to yourself to find out how you could. There will come a time when it precents you from losing your work. If you don't want to host your own server, you can get free or inexpensive hosting. This site has comparisons of free and paid sites using Subversion. If you're feeling brave and want to run your own Subversion server, this site has a free one. It doesn't matter which you use though, just as long as you use one. Note: Many VCS and DVCS come with a way to compare two files to show what's changed. If the one you have doesn't, then meldmerge (pictured) is an open source file comparison utility by Kai Willadsen that works well with several VCS/DVCS.