Rules for Effective Source Code Control
Most developers have at least tried using a source code control system at one time or another. If you're working on a development project as part of a team, such a system is practically indispensible as a way to prevent team members from tripping on each other's changes. Even if you're working all by yourself, source code control can provide a valuable safety net, saving a separate copy of your code in a secure repository and providing you a way to undo major mistakes.
But just how effective is your source code control? Like other parts of the development world, there are ways to make source code control work harder on your behalf. In this article, I'll give you some tips on getting the most out of your source code control system.
Rule #1: Choose the Right System
There are many source code control systems on the market. Rather than just picking the one you know about, or the one that comes for free with your IDE, it's worth taking the time to seriously evaluate the alternatives. You'll probably find some that fit in better with your development style than others. Here are a few factors to consider:
- Price - Some systems are free. Others will cost you hundreds of dollars per user (or even more).
- Concurrent development style - Some systems require you to actively check out code before working on it. Others let you change anything you like, and then merge the changes when you're ready to commit them.
- Repository - Does the system store data in a database, or in the file system? Are you comfortable with the safety and security of the repository?
- Internet friendliness - If your team is geographically distributed, make sure that the system you choose works well over TCP/IP, without using up excessive bandwidth.
- IDE integration - Some people really care whether the can perform source code control operations from within their IDE. Others don't.
- Cross-platform support - If you need to do development on more than one platform (say, Windows and Linux), you'll want a system that works on both platforms.
There are lots of different systems out there to choose from. Without looking into the enterprise market, here are a few you might like to consider (listed in alphabetical order so as not to play favorites):
Rule #2: Put the Right Things in the System
Smart teams use the source code control repository for more than just source code. The key is to store any artifact that's not easily rebuilt from other artifacts. I use "Artifact" as a general term for anything having to do with your software product. Here are a few things you might consider storing in your source code control system:
- Source code
- Windows Installer databases
- Database build scripts
- Icons, bitmaps, and other graphics
- License files
- Readme files
- Informal development notes
- Help files
- Build scripts
- Test scripts
Having everything in one place makes life much simpler when you're faced with the inevitable support request for an older version of your product. You can take a clean machine, get a copy of everything that was involved in version 2.15, rebuild and you're off. This is much easier than trying to collect source code from one place, database scripts from another, and bitmaps from a third - if anyone even bothered to save old database scripts.
Remember, too, that once you store something in the system, you must manage it through the system. Don't let developers (or anyone else) copy things off to a private sandbox with the intent of checking them in later. Once a file escapes from source code control, you'll lose the ability to easily re-create the state of your project at a point in time.