~~SLIDESHOW~~

====== 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 =====
  * [[http://git-scm.com/|Git]]: Arguably the most the popular system today. Distributed system originally created for Linux kernel development.
  * [[https://www.mercurial-scm.org/|Mercurial]]: An elegant distributed system.
  * [[http://bazaar.canonical.com/en/|Bazaar]]: Originally proprietary (Canonical), now FOSS.
  * [[http://subversion.apache.org/|SVN]]: "CVS done right," once very popular.
  * [[http://www.nongnu.org/cvs/|CVS]]: A classic and despised by many.
===== 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."
  * With some VCS, if you lose the repository, you lose all the history or even 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.

===== Navigating revisions =====
  * 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 =====
  * [[http://semver.org/|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 system((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).)):
    * **{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 as((Ibid. Emphasis added.)):
    * **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.

===== Getting started with git =====
  * See [[Git basics]].

===== Endcruft =====
This content is Copyright © 2011-2019 Mithat Konar