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/20 19:32] – [Single-user vs. multi-user scenarios] mithatversion_control:introduction_to_version_control_systems [2019/02/21 18:50] – [Backing up is not a core function!] 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 scenarios =====+===== 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 ===== 
-  * [[https://git-scm.com/downloads|Install git]] +  * A **release** or a **version** is a revision that has has been published for general use. 
-    * [[https://confluence.atlassian.com/bitbucket/set-up-git-744723531.html|Altassian's guides]] +    * An arbitrary determination made by the developers, not necessarily a VCS concept. 
-    * [[https://help.github.com/articles/set-up-git/|GitHub's guides]] (the Windows stuff covers git based on their own Desktop Client). +  * Typically there are several revisions (commits) between releases/versions.
-  * You will need to know how to open an appropriate command line interface (i.e., "terminal" or "command prompt window") in your OS.+
  
-===== Basic operations with git ===== +===== Revision and version numbering ===== 
-  * Create a repository: <code bash>git init</code> +  * A VCS typically automatically assigns identifiers to revisions. 
-  * Add a new file or the changes to an existing file to the repository: <code bash>git add {filename}</code> +  * Identifiers for releases (i.e., the version number) are usually up to the developer.
-  * Add all new and changed files to the repository: <code bash>git add *</code> +
- +
-===== Basic operations with git ===== +
-  * Commit the staged ("added") changes: <code bash>git commit -m "A message about this commit."</code> +
-  * Get status of repository: <code bash>git status</code> +
-  * Get history of repository: <code bash>git log</code> +
- +
-===== GUI interface ===== +
-  * ''git gui'': opens a GUI for performing common git functions  +
-  * ''gitk'': opens a GUI commit browsing tool. +
-  * Other third party git tools are available. +
- +
-===== More git stuff ===== +
-  * Roger Dudler's [[https://rogerdudler.github.io/git-guide/|git - the simple guide]] is beginner friendly and quite good. +
- +
-===== 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.+
  
-===== Version numbering ===== +===== Semantic versioning ===== 
-  * A VCS will typically automatically assign identifiers for revisions. +  * [[http://semver.org/|Semantic versioning]] summarizes a commonly used version numbering scheme. 
-  * Identifiers for releases (i.e., the "version number") are up to you.+    * **{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.
  
-===== Version numbering =====+===== 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 117: 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-2016 Mithat Konar
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