# EDA

version_control:introduction_to_version_control_systems

# Introduction to Version Control Systems

Mithat Konar

## Many names, same thing

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

## Examples

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

## Primary functions

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

## Secondary functions

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

## Backing up is not a core function!

• 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.”
• Depending on the VCS you use, if you lose the repository, you may lose all the history—or the entire project.

## Centralized versus distributed

• Two main groups of VCS:
• Centralized
• Distributed

## Centralized systems

• 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

## Distributed systems

• 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

## Revisions

• 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

• 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

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

## Single-user vs. multi-user

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

## Releases and versions

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

## Revision and version numbering

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

## Semantic versioning

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

## Microsoft version numbering

• The Microsoft system1):
• {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 version numbering

• Microsoft defines these as2):
• 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.

## Other versioning schemes

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

## Endcruft

This content is Copyright © 2011-2016 Mithat Konar

1)
Microsoft, Inc. “Version Class (System).” MSDN | Microsoft Development, Subscriptions, Resources, and More. http://msdn.microsoft.com/en-us/library/system.version.aspx#Y171 (accessed March 9, 2011).
2)