version_control:introduction_to_version_control_systems
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
version_control:introduction_to_version_control_systems [2016/04/25 23:13] – mithat | version_control:introduction_to_version_control_systems [2019/02/21 18:52] (current) – [Endcruft] mithat | ||
---|---|---|---|
Line 12: | Line 12: | ||
===== Examples ===== | ===== Examples ===== | ||
* [[http:// | * [[http:// | ||
- | * [[http://mercurial.selenic.com/ | + | * [[https://www.mercurial-scm.org/ |
* [[http:// | * [[http:// | ||
- | * [[http://www.nongnu.org/cvs/|CVS]]: A classic. Despised by many. | + | * [[http://subversion.apache.org/|SVN]]: "CVS done right," |
- | * [[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 // | + | * //The primary reason for using VCS isn' |
* 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 // | * The server holds // | ||
- | | + | |
* When a user is finished editing, it is " | * When a user is finished editing, it is " | ||
- | * 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. | + | |
- | * Users synchronize | + | |
+ | * 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** | + | * **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 |
* 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**: |
* 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**: |
- | * Applying a bugfix to the current release. | + | * Applying a security update |
- | * 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 |
* Typically there are several revisions (commits) between releases/ | * Typically there are several revisions (commits) between releases/ | ||
- | ===== Version | + | ===== Revision and version |
- | * A VCS will typically automatically | + | * A VCS typically automatically |
- | * Identifiers for releases (i.e., the "version number") are typically | + | * Identifiers for releases (i.e., the version number) are usually |
- | ===== Version | + | ===== Semantic versioning ===== |
+ | * [[http:// | ||
+ | * **{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 | ||
* The Microsoft system((Microsoft, | * The Microsoft system((Microsoft, | ||
* **{major}.{minor}.{build}.{revision}** | * **{major}.{minor}.{build}.{revision}** | ||
Line 93: | Line 102: | ||
* {revision} here does not have the same meaning as // | * {revision} here does not have the same meaning as // | ||
- | ===== Version | + | ===== Microsoft version |
* 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 '' | + | |
- | * e.g.: '' | + | |
- | * 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.: '' | + | * Some projects use date-based versioning. |
+ | * '' | ||
+ | * '' | ||
* Whatever you do, be consistent and meaningful. | * Whatever you do, be consistent and meaningful. | ||
Line 117: | Line 119: | ||
===== 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.txt · Last modified: 2019/02/21 18:52 by mithat