- Mike Mason
- Software Engineering/Operating Systems
If you program applications or develop web-sites there will always be a time, usually late at night or when you’re in a rush, when you make a change thinking that it will improve the final product no-end. Only to find, a few days later, that the change you made in haste was not such a good idea. Now if you could only remember what the original code was like.
Being an application developer this happens to me at work all the time. When the company that I work for had five full time developers, things started to get out of hand. All of us were working on one application, all in the same directory and all of us were doing “makes” at the same time. So we started to use CVS for version control. Once we understood how it all worked: checking code out of the repository, committing and updating, it all worked like a charm. We could see who had made what changes and when and how long a bug had lain dormant in the application. Good news if the person doing the testing swears blind that it worked fine a few months ago.
So, when I started to tinker with Ruby On Rails and AppleScript I decided that even I could do with version control at home. I found that, although CVS is still widely used, Subversion has become an up-to-date alternative.
I found the book a quick read, mainly due to my use of CVS in the past. The author explains the overwhelming need for version control and guides the reader through the basics, using scenarios and examples, before explaining the trickier ‘branches’ and ‘tags’ concepts later on. The book also covers installation, conversion from CVS and the all important backup and restore of the main repository.
It does seem a little scary to have all your source code in one place being managed by an application but once you have taken the first steps you’ll never look back.