I wrote this article for my work’s public blog – go there and post comments so I look cool 🙂
As a developer, I believe that proper version control is one of the most important things you can do in your development process. It is more important than quality documentation, more important than code commenting, and more important that unit-testing. It doesn’t matter if you use Subversion, Perforce, Git, Mercurial, Bazaar, or even 20yr old CVS, as long as you use it. If you don’t, then you are asking for trouble.
Imagine this scenario: You have just spent the past day working on a complex script to solve a huge problem. Having finally completed the script, cleaned up your code-comments, written your documentation and successfully run it through your local automated test-suite, you are about ready to send off the code to your production server for release.
Suddenly your computer emits a large bang and your screen flicks black.
It refuses to start when you click the power button, and upon examination of the insides you find a family of mice has made a nest next to your hard drive, causing it to overheat and explode.
The results: Not only have you destroyed the home of a family of mice, but your script is gone – completely unrecoverable. So much for your beautiful code-comments, and that amazing documentation. They won’t give you back the hard work you put in. Sure, you can re-write it, and may even have snippets of code around that you can use to re-construct it, but this will take time and effort.
A less drastic scenario: You accidentally overwrite a block of important code without realising it. You save the file and close the editor. No amount of Ctrl+Z will save you from that. Again, you may have a copy of the code somewhere, but if you have version control it is a piece of cake to revert to the older version. Sure, you might be able to find the code somewhere else, but you can’t always rely on it and it’s never as easy as using the standard features of a version control system.
Now, I’m not just saying you create a Repository on your local machine and use that for your version control. You’ll still have a single point of failure. Instead, what you need to do is set up your repository within a redundant environment which is independent to your development environment. This will ensure that you can lose your dev environment or part of your redundant repository environment and not lose your code.
At Uber, we use Subversion as our main version control system. Development takes place either on local workstations or custom development machines. We then have a dedicated version control server upon which our Subversion repositories are stored. This machine is backed up using our automated backup system (CDP) to ensure that if we lose that box, we won’t lose our repositories. To top it off, we are constantly committing our changes to the repositories to ensure that if we lose a workstation/dev box, we don’t lose too much work.
After putting in a bit of initial effort, you will end up with proper version control which is easy to maintain and ensures your hard work isn’t lost.
The way it should be.