Code Versioning -- Don't Leave Home Without It

It's worth the time and effort exerted to get a code versioning system up and running, even if only locally. At small shops and startups, the typical system is to create zip archives of source folders and to store them on a file server. That's well and good but it ultimately fails for long term development.

Basic questions such as when a specific feature was implemented or what changed from one version of the software to another are left out. Additionally, you can forget about more than one person working on the code at a time.

Code versioning systems handle these problems. There are many flavors of these systems to choose from: the older CVS, the relative newcomer SVN or the hot kid on block, git. Git was the brain child of Linus Torvalds who was dissatisfied with the field, so he rolled his own. Git repositories are springing up everywhere. Apple's Xcode IDE uses git natively. Most flavors of Eclipse have CVS hiding in the back-ground. Visual Studio leans towards Team Foundation (previously SourceSafe).

Alternate versioning systems can use a desktop client. TortoiseSVN or TortoiseCVN integrates into file browsers.

Code versioning allows code to be checked out, modified and checked back in with a description of the changes. Some distributed build tools, such as Hudson/Jenkins can pick up on these labels and trigger a build. Bug reporting tools like Bugzilla can also play a role in the versioning process.

The entire build process can grow as the process grows, but should always start with a good choice in coding versioning.

It all starts with a repository. This is simply a folder that has been designated to hold all the code and all the versions of code. Once established, adding projects is pretty simple. One person generates the initial source project and then "shares" it, which means copying it to the repository. Files and resources can be committed.

The second stage is checking out the code by another developer and then cooperatively working on the source. Code versioning isn't a magic bullet for teams. This needs to be handled by agreed-upon management. But, if something breaks, use the system to back out changes. In that case, the system is priceless.

The versioning systems all have a lot of the same features: tagging, branching, forking, rebasing, etc. These are all wonderful, but the greatest gift of all is the ability to figure out when something stopped working and quickly restore sanity to the project.