Here is a table of the decisions that revision control systems have to make. The three columns each represent something that every revision control system must decide upon.
History - This is the aspect of a revision that is considered essential.
Revision IDs - This is the way that the RCS internally names the revision for purposes of tracking, merges, etc.
Rename Handling - How the RCS records file renames and apply them when doing updates and merges.
History |
Revision IDs |
Rename Handling |
Snapshot |
Hashes |
Unique IDs |
Changeset |
Namespace |
History tracking |
Semantic Patch |
Pseudo-random |
None |
Examples
Name |
History |
Revision IDs |
Rename Handling |
Bazaar-NG |
Snapshot |
Pseudo-random |
Unique IDs |
Changeset |
Namespace |
Unique IDs |
|
Subversion |
Snapshot |
Namespace |
History tracking |
git |
Snapshot |
Hashes |
File content |
Darcs |
Patch |
Namespace |
History tracking |
quilt |
Patch |
Namespace |
None |
Mercurial |
Snapshot |
Hashes |
History tracking |
Matrix
The "History" axis is denoted in brackets after the name of the VCS.
Revision / Rename |
None |
History |
Unique IDS |
Namespace |
quilt (patch) |
Darcs (patch), SVN (snap) |
Arch (cset) |
Hashes |
GIT (snap) |
Mercurial (snap) |
|
Pseudo-random |
|
|
Bazaar-NG (snap) |
Merge handling
Possibly this is a function of history, but another important decision is how to handle merges and branches. Eg monotone - commits to the same revision always create new branches