The primary goal of software development is to solve problems, not to perform elaborate rituals with version control systems or other tools (IDE's, Makefiles, e

The primary goal of software development is to solve problems, not to perform elaborate rituals with version control systems or other tools (IDE's, Makefiles, etc.). The primary function of a version control system is to recover earlier versions of the software in rare error situations where it is hard to figure out what has gone wrong. Backup to something that worked and identify the change that caused the problem. For most software developers, a version control system should appear very simple so they can focus on solving the end user or customer or their own problem. check-in <file | folder> o if the file is new for the project, the VCS should ask do you want to add this to the project? o check-in <folder> checks everything in the folder (directory) all at once. If the folder is new: do you want to add this folder to the project? checkout <file | folder | project> [ <version> ] o checkout <file> checks out the most recent version of the file <file>. o checkout <folder> checks out the most recent versions of the files in <folder> and its sub-folders o checkout <project> checks out the most recent version of the entire project. The project can just be the specification of the top level folder! o <version> is an easy, human readable/understandable specification of the earlier version, a file sequence number such as 1.43, a folder or module sequence number, or an overall project sequence number (all generated automatically by the VCS -- at least by default). All sorts of pain and suffering is avoided by dividing the project into folders for different components and contributors and/or teams. These check-in/check-out their folder independently. The VCS should be very simple and take care of everything, such as maintaining a sequential overall project number as well as file sequence numbers, automatically behind the scenes. For a single developer or a team in the same office or building or for that matter office park with a fast network, that is all you need. For remote collaboration -- such as China and USA -- then you might need one or two command to push/pull the code to remote repositories; this too should be simple! KISS (Keep It Simple Stupid)