Introduction to Version Control Systems

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.
• SVN: “CVS done right,” once very popular.
• CVS: A classic and despised by many.

• 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 isn't 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.”
• With some VCS, if you lose the repository, you lose all the history or even 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 “check out” one or more source files for editing.
  • When a user is finished editing, it is “checked in” to the server.
  • Often, only one user at a time can check out a given file.
• CVS, SVN

• Replacing centralized systems.
• Uses a peer-to-peer architecture.
  • Individual users have complete, fully editable repositories.
  • Users synchronize 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

• revision: 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.
• Also called a commit, snapshot, or changeset.
• 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.

• 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 branching.

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

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

• A release or a version is a revision that has has been published for general use.
  • An arbitrary determination made by the developers, not necessarily a VCS concept.
• Typically there are several revisions (commits) between releases/versions.

• A VCS typically automatically assigns identifiers to revisions.
• Identifiers for releases (i.e., the version number) are usually up to the developer.

• Semantic versioning summarizes a commonly used version numbering scheme.
  • {major}.{minor}.{patch}
  • major: there are incompatible API changes,
  • minor: added functionality in a backwards-compatible manner.
  • patch: backwards-compatible bug fixes.
  • Additional labels for pre-release and build metadata.
    • alpha, beta, release candidate.

• 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.
  • minor: significant enhancement with the intention of backward compatibility.
  • build: a recompilation of the same source.
  • revision: intended to be fully interchangeable.

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

• See Git basics.

This content is Copyright © 2011-2019 Mithat Konar