Differences

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

--- version_control:introduction_to_version_control_systems [2016/11/27 23:20] – mithat
+++ version_control:introduction_to_version_control_systems [2016/11/27 23:47] – mithat
@@ Line 47: / Line 47: @@
 ===== Distributed systems =====
   * Replacing centralized systems.
-  * Distributed systems use a peer-to-peer architecture.
+  * Uses a peer-to-peer architecture.
-  * Individual users have complete, fully editable repositories.
+    * Individual users have complete, fully editable repositories.
-  * Users synchronize their repositories with each other as needed.
+    * 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.
@@ Line 55: / Line 55: @@
 ===== 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.
-  * 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.
@@ Line 65: / Line 65: @@
 ===== Branching =====
-  * **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 develop a bugfix.
@@ Line 71: / Line 71: @@
 ===== Merging =====
-  * **Merging**: incorporating changes from a different branch or another repository.
+  * **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.
@@ Line 79: / Line 79: @@
 ===== Releases and versions =====
-  * A revision 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; often an arbitrary determination made by the developers.
+    * An arbitrary determination made by the developers, not necessarily a VCS concept.
   * Typically there are several revisions (commits) between releases/versions.
@@ Line 89: / Line 89: @@
 ===== Semantic versioning =====
   * [[http://semver.org/|Semantic versioning]] summarizes a commonly used version numbering scheme.
-    * **{major}.{minor}.{path}**
+    * **{major}.{minor}.{patch}**
-    * **major**: version when you make incompatible API changes,
+    * **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 release, beta release, release candidate.
+        * alpha, beta, release candidate.
 ===== Microsoft version numbering =====
@@ Line 111: / Line 111: @@
 ===== 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.