Mithat Konar (the wiki)

User Tools

Site Tools

You are here: Mithat Konar (the wiki) » Version Control » Introduction to Version Control Systems
version_control:introduction_to_version_control_systems

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
version_control:introduction_to_version_control_systems [2016/04/20 21:39] – mithatversion_control:introduction_to_version_control_systems [2019/02/21 18:52] (current) – [Endcruft] mithat
Line 11: Line 11:
  
 ===== Examples ===== ===== Examples =====
-  * [[http://git-scm.com/|Git]]: Distributed system originally created for Linux kernel development. Likely most the popular system today. +  * [[http://git-scm.com/|Git]]: Arguably the most the popular system today. Distributed system originally created for Linux kernel development. 
-  * [[http://mercurial.selenic.com/|Mercurial]]: An elegant distributed system.+  * [[https://www.mercurial-scm.org/|Mercurial]]: An elegant distributed system.
   * [[http://bazaar.canonical.com/en/|Bazaar]]: Originally proprietary (Canonical), now FOSS.   * [[http://bazaar.canonical.com/en/|Bazaar]]: Originally proprietary (Canonical), now FOSS.
-  * [[http://www.nongnu.org/cvs/|CVS]]: A classic. Despised by many. +  * [[http://subversion.apache.org/|SVN]]: "CVS done right," once very popular. 
-  * [[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 ===== ===== Primary functions =====
   * Create a **repository** to store all the source code for a project.   * Create a **repository** to store all the source code for a project.
Line 24: Line 23:
   * Permit moving back and forth through different **revisions** (i.e., the history) of the project.   * Permit moving back and forth through different **revisions** (i.e., the history) of the project.
   * Allow **branching** and **merging** of revisions.   * Allow **branching** and **merging** of revisions.
-  * Let multiple users (a team) share and integrate code.+  * Let multiple users (a team) **share and integrate** code.
  
 ===== Backing up is not a core function! ===== ===== Backing up is not a core function! =====
-  * The primary reason for using VCS is //not// backing up your code!+  * //The primary reason for using VCS isn't backing up your code!//
   * The VCS you use may suck as a backup system.   * The VCS you use may suck as a backup system.
   * Backing up is something you may or may not get "for free."   * 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.+  * With some VCS, if you lose the repository, you lose all the history or even the entire project.
  
 ===== Centralized versus distributed ===== ===== Centralized versus distributed =====
Line 40: Line 39:
   * Early systems were based on a centralized client-server architecture.   * Early systems were based on a centralized client-server architecture.
   * The server holds //TheOneHolyRepository™//.   * The server holds //TheOneHolyRepository™//.
-  * Clients are allowed to "check out" one or more source files for editing.+    * Clients "check out" one or more source files for editing.
     * When a user is finished editing, it is "checked in" to the server.     * 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.+    * Often, only one user at a time can check out a given file.
   * CVS, SVN   * CVS, SVN
  
 ===== Distributed systems ===== ===== Distributed systems =====
-  * Distributed systems use a peer-to-peer architecture. 
   * Replacing centralized systems.   * Replacing centralized systems.
-  * Individual users have complete, fully editable repositories. +  * Uses a peer-to-peer architecture. 
-  * Users synchronize their repositories with each other as needed.+    * 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.   * Managing can be more complicated for groups, but is more flexible.
   * Can be configured to work like to a centralized system.   * Can be configured to work like to a centralized system.
Line 55: Line 54:
  
 ===== Revisions ===== ===== Revisions =====
-  * A **revision** is a snapshot of the state of a project at a given moment.+  * **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.   * 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**.+  * Also called a **commit**, **snapshot**, or **changeset**.
   * If needed, differences between the most recent state and older revisions can be determined.   * If needed, differences between the most recent state and older revisions can be determined.
  
Line 65: Line 64:
  
 ===== Branching ===== ===== Branching =====
-  * Many VCS's facilitate **branching**: making a copy of the project whose development will go in parallel with the original.+  * **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 test ideas that develops in parallel with the main release.
     * A branch to develop a bugfix.     * A branch to develop a bugfix.
 +  * Many VCS's facilitate branching.
  
 ===== Merging ===== ===== Merging =====
-  * Many VCS's facilitate **merging**: incorporating changes from a branch or another repository. +  * **merging**: incorporating changes from a different branch or another repository. 
-    * Applying a bugfix to the current release. +    * Applying a security update or bugfix developed for a 1.1 release to the 1.0 release. 
-    * Applying a security update developed for a 2.0 release to the 1.0 releases.+  * Many VCS's facilitate merging.
  
 ===== Single-user vs. multi-user ===== ===== Single-user vs. multi-user =====
   * How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one.   * How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one.
  
-===== Getting started with git ===== +===== Releases and versions ===== 
-  * See [[Git basics]]. +  * 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.
-===== Revisions vs. versions ===== +
-  * A revision (i.e., commit or snapshot) that has has been published for general use is a //release// or a //version//. +
-  * Often //not// a VCS concept but an arbitrary determination by the developers.+
   * Typically there are several revisions (commits) between releases/versions.   * Typically there are several revisions (commits) between releases/versions.
  
-===== Version numbering ===== +===== Revision and version numbering ===== 
-  * A VCS will typically automatically assign identifiers for revisions. +  * A VCS typically automatically assigns identifiers to revisions. 
-  * Identifiers for releases (i.e., the "version number") are up to you.+  * Identifiers for releases (i.e., the version number) are usually up to the developer.
  
-===== Version numbering =====+===== 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).)):   * 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}**     * **{major}.{minor}.{build}.{revision}**
Line 96: Line 102:
     * {revision} here does not have the same meaning as //revision// used above (i.e., //commit// or //changeset//).     * {revision} here does not have the same meaning as //revision// used above (i.e., //commit// or //changeset//).
  
-===== Version numbering =====+===== Microsoft version numbering =====
   * Microsoft defines these as((Ibid. Emphasis added.)):   * Microsoft defines these as((Ibid. Emphasis added.)):
-    * **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. +    * **major**: different major versions are not interchangeable. 
-    * **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. +    * **minor**: significant enhancement with the intention of backward compatibility. 
-    * **Build**: //... a recompilation of the same source.// Different build numbers might be used when the processor, platform, or compiler changes. +    * **build**: a recompilation of the same source. 
-    * **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.+    * **revision**: intended to be fully interchangeable.
  
-===== Version numbering ===== +===== Other versioning schemes ===== 
-  * Another common system is **{major}.{minor}.{maintenance}**. +  * Some projects use date-based versioning. 
-  * {maintenance} is essentially MS's {revision}. +    * ''2015.06.23'' 
-  * The character ''a'' is often used to indicate an alpha release, ''b'' for beta, ''rc'' for a release candidate. +    * ''15.033''
-    * 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. +
- +
-===== Version numbering ===== +
-  * Some projects use date-based versioning, e.g.: ''2015.06.23'', ''15.033'', etc. +
   * Whatever you do, be consistent and meaningful.   * Whatever you do, be consistent and meaningful.
 +
 +===== Getting started with git =====
 +  * See [[Git basics]].
  
 ===== Endcruft ===== ===== Endcruft =====
-This content is Copyright © 2011-2016 Mithat Konar+This content is Copyright © 2011-2019 Mithat Konar
version_control/introduction_to_version_control_systems.1461188390.txt.gz · Last modified: 2016/04/20 21:39 (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki