Version control systems (VCS), also known as revision control, or source control management (SCM), are systems that track the changes to files. It is a common tool in software development, providing logical way to organise and control revisions to the source code, with multiple contributors working simultaneously.
There are three main approaches to VCS, local (LVCS), centralised (CVCS), and distributed (DVCS). The most commong local method is to make a copy of the codebase in another directory; this approach is common but hightly error prone. As the local method is trival, it will not be covered here. Previously, almost all non-local VCS were centralised, like CVS (Concurrent Versions System) and SVN (Apache Subversion).
The centralised model has one centralised repository, thus for security and integrity of your codebase, you only allowed a few authors the ability to commit changes to the codebase. There were many issues with this model:
- Single point of failure
- Remote commits are slow (network required)
- Unsolicited changes may break builds
- Merging is painful
This model seems to promote committing less frequent, large changes.
The distributed model is fundamentally different, in that there is not centralised repository, each developer works on a local version, which is theirs; however, it can be hard to keep track of everyone’s changes to the codebase. This covers the aforementioned issues:
- Each developer has their own copy
- Local commits (no network required)
- Continuous changes to codebase, with asynchronous reviewing
- Merging is easier
This model promotes committing frequent, small changes. A common expression with DVCS is “commit early, commit often”; the granularity of smaller changes allows for faster issue/bug tracking and merging of codebases.
There is nothing stopping a slight hybrid of both models. The distributed model allows for a centralised repository should one be required; it’s just another copy of the codebase. This would allow all the benefits of working with the distributed model, but with the benefit of a single, safe, preferred, point of contact.
The developers commit to their own copy of the code, and rather than requesting to each other to merge their changes, they request the ‘central’/upstream repository merge their changes. You can then have dedicated code integrity experts review the changes before accepting them. The other developers can then choose to merge the upstream changes to their own code, with the knowledge it is unlikely to break anything.
DVCS is the more common tool to use in modern software development, using either Git or Mercurial.