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
Last revisionBoth sides next revision
version_control:introduction_to_version_control_systems [2016/04/25 23:13] – mithatversion_control:introduction_to_version_control_systems [2019/02/21 18:50] – [Backing up is not a core function!] mithat
Line 12: Line 12:
 ===== Examples ===== ===== Examples =====
   * [[http://git-scm.com/|Git]]: Arguably the most the popular system today. Distributed system originally created for Linux kernel development.   * [[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.
  
-===== Revisions vs. versions ===== +===== Releases and versions ===== 
-  * A revision (i.e., commit or snapshot) that has has been published for general use is a **release** or a *version*. +  * A **release** or a **version** is a revision that has has been published for general use. 
-  * Not necessarily a VCS concept but rather an arbitrary determination by the developers.+    * An arbitrary determination made by the developers, not necessarily a VCS concept.
   * 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 typically 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 93: 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 ===== +
-  * Another common system is **{major}.{minor}.{maintenance}**. +
-  * {maintenance} is essentially MS's {revision}. +
-  * The character ''a'' is often used to indicate an alpha release, ''b'' for beta, ''rc'' for a release candidate. +
-    * 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 ===== +===== Other versioning schemes ===== 
-  * Some projects use date-based versioning, e.g.: ''2015.06.23'', ''15.033'', etc. +  * Some projects use date-based versioning. 
 +    * ''2015.06.23'' 
 +    * ''15.033''
   * Whatever you do, be consistent and meaningful.   * Whatever you do, be consistent and meaningful.
  
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