Mithat Konar

• Version Control System (VCS)
• Revision Control System (RCS)
• Source Control (SC)
• Source Control Management (SCM)

• Git: Arguably the most the popular system today. Distributed system originally created for Linux kernel development.
• Mercurial: An elegant distributed system.
• Bazaar: Originally proprietary (Canonical), now FOSS.
• CVS: A classic. Despised by many.
• SVN: “CVS done right.” Once very popular.

• Create a repository to store all the source code for a project.
• Maintain a complete history of the changes to the source code for a project.

• Permit moving back and forth through different revisions (i.e., the history) of the project.
• Allow branching and merging of revisions.
• Let multiple users (a team) share and integrate code.

• The primary reason for using VCS is not backing up your code!
• The VCS you use may suck as a backup system.
• Backing up is something you may or may not get “for free.”
• Depending on the VCS you use, if you lose the repository, you may lose all the history—or the entire project.

• Two main groups of VCS:
  • Centralized
  • Distributed

• Early systems were based on a centralized client-server architecture.
• The server holds TheOneHolyRepository™.
• Clients are allowed to “check out” one or more source files for editing.
  • When a user is finished editing, it is “checked in” to the server.
  • Only one user at a time can check out a given file.
• CVS, SVN

• Distributed systems use a peer-to-peer architecture.
• Replacing centralized systems.
• Individual users have complete, fully editable repositories.
• Users synchronize their repositories with each other as needed.
• Managing can be more complicated for groups, but is more flexible.
• Can be configured to work like to a centralized system.
• Git, Mercurial, Bazaar

• A revision is a snapshot of the state of a project at a given moment.
• When a meaningful change to the code of a project is completed, a revision incorporating that change is committed (placed) into the repository.
• Revisions are also called commits, snapshots, and changesets.
• If needed, differences between the most recent state and older revisions can be determined.

• Many VCS's let users move back to older revisions of files or the whole project.
• Details are system dependent.

• Many VCS's facilitate branching: making a copy of the project whose development will go in parallel with the original.
  • A branch to test ideas that develops in parallel with the main release.
  • A branch to develop a bugfix.

• Many VCS's facilitate merging: incorporating changes from a branch or another repository.
  • Applying a bugfix to the current release.
  • Applying a security update developed for a 2.0 release to the 1.0 releases.

• How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one.

• A revision (i.e., commit or snapshot) that has has been published for general use is a release or a *version*.
• Not necessarily a VCS concept but rather an arbitrary determination by the developers.
• Typically there are several revisions (commits) between releases/versions.

• A VCS will typically automatically assign identifiers for revisions.
• Identifiers for releases (i.e., the “version number”) are typically up to you.

• The Microsoft system¹⁾:
  • {major}.{minor}.{build}.{revision}
  • e.g.: 5.50.4807.2300
  • {build} and {revision} are optional.
  • {revision} here does not have the same meaning as revision used above (i.e., commit or changeset).

• Microsoft defines these as²⁾:
  • Major: … different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.
  • Minor: … significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.
  • Build: … a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
  • Revision: … intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

• Another common system is {major}.{minor}.{maintenance}.
• {maintenance} is essentially MS's {revision}.
• The character a is often used to indicate an alpha release, b for beta, rc for a release candidate.
  • e.g.: 4.5b2
  • The last alpha should become the first beta.
  • The last beta should become the first release candidate.
  • The last release candidate should become the first full release.

• Some projects use date-based versioning, e.g.: 2015.06.23, 15.033, etc.
• Whatever you do, be consistent and meaningful.

• See Git basics.

This content is Copyright © 2011-2016 Mithat Konar