User Tools

Site Tools


No renderer 'pdf' found for mode 'pdf'
version_control:introduction_to_version_control_systems

View page as slide show

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.
  • SVN: “CVS done right,” once very popular.
  • 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.
  • 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.

Getting started with git

Endcruft

This content is Copyright © 2011-2019 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)
Ibid. Emphasis added.
version_control/introduction_to_version_control_systems.txt · Last modified: 2019/02/21 18:52 by mithat

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki