Discussion

Nearly all nontrivial projects need more than one developer and/or take more than a week of work. On such projects, you will need to compare historical versions of the same file to determine when (and/or by whom) changes were introduced. You will need to control and manage source changes.

When there are multiple developers, those developers will make changes in parallel, possibly to different parts of the same file at the same time. You need tools to automate checkout/versioning of file and, in some cases, merging of concurrent edits. A VCS automates and controls checkouts, versioning, and merging. A VCS will do it faster and more correctly than you could do it by hand. And you don't have time to fiddle with administriviayou have software to write.

Even a single developer has "oops!" and "huh?" moments, and needs to figure out when and why a bug or change was introduced. So will you. A VCS automatically tracks the history of each file and lets you "turn the clock back." The question isn't whether you will want to consult the history, but when.

Don't break the build. The code in the VCS must always build successfully.

The broad range of VCS offerings leaves no excuse not to use one. The least expensive and most popular is cvs (see References). It is a flexible tool, featuring TCP/IP access, optional enhanced security (by using the secure shell ssh protocol as a back-end), excellent administration through scripting, and even a graphical interface. Many other VCS products either treat cvs as a standard to emulate, or build new functionality on top of it.