Version Control and Project Management
Overview
Rarely is software developed solely by one person, sometimes it is developed by two, but most software involves the work of five or more people. Sometimes these people are in the same room, and sometimes they are spread out all over the world. Whenever a project has multiple people working at the same time you will inevitably have situations where their work overlaps. Perhaps two people will have to perform bug fixes on the same file, maybe they will all be adding APIs to a library. In these situations you always run the risk of one person overwriting the work of another. As your group grows in number and in geographic distance these problems become an even bigger problem. A good version control system (like CVS or Perforce) can help to solve these problems.Scenario A: At 1100 Jose from San Diego begins to fix a bug in the bar method found in foo.py. While he is working on this problem Armen from Yerevan has opened his copy of foo.py and begun to add the baz method to foo.py. At 1115 Armen, being a fast and efficient coder, finishes his addition and saves the file and then copies his changes to the server. Two minutes later (1117) Jose has finished his bug fix and copies his version of the file to the server. Much to Armen's chagrin his baz method has been overwritten and lost forever.
Scenario A (with CVS): At 1100 Jose from San Diego begins to fix a bug in the bar method found in foo.py. While he is working on this problem Armen from Yerevan has opened his copy of foo.py and begun to add the baz method to foo.py. At 1115 Armen, being a fast and efficient coder, finishes his addition and saves the file and then commits his changes to the server. Two minutes later (1117) Jose has finished his bug fix and attempts to commit his change to the server. The server seeing that Jose's file is older then the version currently on the system refuses to commit Jose's file. Jose runs an update from the server merging Armen's changes with his code changes. Jose spends a minute making sure that none of the changes affect the same block of code (if they did he would simply merge both changes together), and commits again. Armen is safe in the knowledge that his changes are not lost forever.
Scenario B: Scott is writing his latest novel. After spending a week agonizing over a passage he saves his novel. A week later he comes back to the novel and decides that he hates that particular passage and in a wave of inspiration rewrites the entire section. After another week he realizes that his "wave of inspiration" was in fact a bucket of stupidity. He wants to go back to his old version but it is sadly lost forever.
Scenario B (with CVS): Scott is writing his latest novel. After spending a week agonizing over a passage he commits the novel to his repository. A week later he comes back to the novel and decides that he hates that particular passage and in a wave of inspiration rewrites the entire section. After another week he realizes that his "wave of inspiration" was in fact a bucket of stupidity. He reviews his cvs commits, finds the commit with which he overwrote his original version and retrieves the old copy. After some cut and paste work he adds the old section back in and commits his copy.
In addition to preventing overwrites and storing a complete history of file changes it also:
- A complete history of work done, allowing developers to track their time and progress
- Branching which allows you to simultaneously maintain production, testing, stable, and unstable versions of the same code
- Provides a back-up situation (which can be located on a totally different machine then yours) to protect against hard disk failure, or the infamous "rm -rf /code" mistake