melbourne chapter

An important tool for any collaborative development environment is the use of version management. There are many flavours of version management including RCS/CVS and SVN. I have preferred using CVS (Concurrent Versioning System) as it has been around for many years and I have found it easy to use.

Using a versioning system allows you to operate a central location for your team development, allowing management of versions across your developers. The infrastructure works similar to as follows; your central development server operates as the CVS Server, and hosts a CVS Repository containing all versions/changes to your files managed by project/modules. Your team developers can “checkout” from their environment and retrieve the latest versions, make changes, and “commit” (with comments) the changes back to the server. When another developer commits changes or performs a “update” their environment is automatically updated with the relevant files. Also, CVS supports watches and locks on files so that you can identify if others are working on the files. As long as the developers are regularly commiting/updating they can generally have piece of mind that they don’t need to make local backups of the work, that they are working on the latest code and have no fear that they will destroy other developers code.
The CVS automatically handles version increments of each file, and can be used to compare previous versions of the file, or revert back to a specific version. The CVS also adds the ability to view the entire project at a specific point of time, such as within a day (or however long) before a major bug is reported in your testing. It also allows you to create tags/branches and versions of the project, such as “version_1_0_0″ etc. CVS can also be setup to deliver mail to other developers notifying them of changes to files (outlining comments, and affected rows using CVS diff commands). As the CVS is centralised and represents your project at any point of time, it can be backed up easily. Remember when you backup your files to ensure that they are encrypted, preferrably with a symmetrical key (consider contingency) for your archive.

CVS can be run via a command line execution, eg, ‘cvs co projectA’ or integrated into your IDE. As this is a very useful tool, many popular IDE’s have support for it natively (Eclipse) and allows you to manage all versions within the application. There are also ways of running it seperate to your IDE (if your IDE doesn’t support it) such as using WinCVS, MacCVS etc. Although since Mac is operating on BSD, you will find that it supports the CVS commands from your terminal screen.

When working in a collaborative environment I have found it crucial, providing piece of mind and quick to ensure everyone is working with the correct files.

For information on using CVS check out the following resources:

• CVS Home (outdated, but good resource documentation)
• Concurrent Version Howto (Documents CVS with WinCVS)
• Installing and operating CVS (Good thorough notes)