Fossil SCM
Added fragment identifiers to the new CAP theorem doc.
Commit
991b0899258dc42d60b0dff632b78268ee31bab3bde6b5e1a36b96aeb1a2654c
Parent
c3b2671f6d5c775…
1 file changed
+3
+3
| --- www/cap-theorem.md | ||
| +++ www/cap-theorem.md | ||
| @@ -11,10 +11,11 @@ | ||
| 11 | 11 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 12 | 12 | [sol]: https://en.wikipedia.org/wiki/Speed_of_light |
| 13 | 13 | [tut]: https://www.ibm.com/cloud/learn/cap-theorem |
| 14 | 14 | |
| 15 | 15 | |
| 16 | +<a id="ap"></a> | |
| 16 | 17 | ## Fossil Is an AP-Mode System |
| 17 | 18 | |
| 18 | 19 | As with all common [DVCSes][dvcs], Fossil is an AP-mode system, meaning |
| 19 | 20 | that your local clone isn’t necessarily consistent with all other clones |
| 20 | 21 | (C), but the system is always available for use (A) and |
| @@ -31,10 +32,11 @@ | ||
| 31 | 32 | There’s no getting around the CAP theorem! |
| 32 | 33 | |
| 33 | 34 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 34 | 35 | |
| 35 | 36 | |
| 37 | +<a id="ca"></a> | |
| 36 | 38 | ## CA-Mode Fossil |
| 37 | 39 | |
| 38 | 40 | What would it mean to redesign Fossil to be CA-mode? |
| 39 | 41 | |
| 40 | 42 | It means we get a system that is always consistent (C) and available (A) |
| @@ -77,10 +79,11 @@ | ||
| 77 | 79 | [CVS]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 78 | 80 | [Kafka]: https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka |
| 79 | 81 | [svn]: https://en.wikipedia.org/wiki/Apache_Subversion |
| 80 | 82 | |
| 81 | 83 | |
| 84 | +<a id="cp"></a> | |
| 82 | 85 | ## CP-Mode Fossil |
| 83 | 86 | |
| 84 | 87 | What if we modify our CA-mode system above with “warm spares”? We can |
| 85 | 88 | say that commits must go to all of the spares as well as the active |
| 86 | 89 | servers, but a loss of one active server requires that one warm spare |
| 87 | 90 |
| --- www/cap-theorem.md | |
| +++ www/cap-theorem.md | |
| @@ -11,10 +11,11 @@ | |
| 11 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 12 | [sol]: https://en.wikipedia.org/wiki/Speed_of_light |
| 13 | [tut]: https://www.ibm.com/cloud/learn/cap-theorem |
| 14 | |
| 15 | |
| 16 | ## Fossil Is an AP-Mode System |
| 17 | |
| 18 | As with all common [DVCSes][dvcs], Fossil is an AP-mode system, meaning |
| 19 | that your local clone isn’t necessarily consistent with all other clones |
| 20 | (C), but the system is always available for use (A) and |
| @@ -31,10 +32,11 @@ | |
| 31 | There’s no getting around the CAP theorem! |
| 32 | |
| 33 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 34 | |
| 35 | |
| 36 | ## CA-Mode Fossil |
| 37 | |
| 38 | What would it mean to redesign Fossil to be CA-mode? |
| 39 | |
| 40 | It means we get a system that is always consistent (C) and available (A) |
| @@ -77,10 +79,11 @@ | |
| 77 | [CVS]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 78 | [Kafka]: https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka |
| 79 | [svn]: https://en.wikipedia.org/wiki/Apache_Subversion |
| 80 | |
| 81 | |
| 82 | ## CP-Mode Fossil |
| 83 | |
| 84 | What if we modify our CA-mode system above with “warm spares”? We can |
| 85 | say that commits must go to all of the spares as well as the active |
| 86 | servers, but a loss of one active server requires that one warm spare |
| 87 |
| --- www/cap-theorem.md | |
| +++ www/cap-theorem.md | |
| @@ -11,10 +11,11 @@ | |
| 11 | [cap]: https://en.wikipedia.org/wiki/CAP_theorem |
| 12 | [sol]: https://en.wikipedia.org/wiki/Speed_of_light |
| 13 | [tut]: https://www.ibm.com/cloud/learn/cap-theorem |
| 14 | |
| 15 | |
| 16 | <a id="ap"></a> |
| 17 | ## Fossil Is an AP-Mode System |
| 18 | |
| 19 | As with all common [DVCSes][dvcs], Fossil is an AP-mode system, meaning |
| 20 | that your local clone isn’t necessarily consistent with all other clones |
| 21 | (C), but the system is always available for use (A) and |
| @@ -31,10 +32,11 @@ | |
| 32 | There’s no getting around the CAP theorem! |
| 33 | |
| 34 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 35 | |
| 36 | |
| 37 | <a id="ca"></a> |
| 38 | ## CA-Mode Fossil |
| 39 | |
| 40 | What would it mean to redesign Fossil to be CA-mode? |
| 41 | |
| 42 | It means we get a system that is always consistent (C) and available (A) |
| @@ -77,10 +79,11 @@ | |
| 79 | [CVS]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 80 | [Kafka]: https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka |
| 81 | [svn]: https://en.wikipedia.org/wiki/Apache_Subversion |
| 82 | |
| 83 | |
| 84 | <a id="cp"></a> |
| 85 | ## CP-Mode Fossil |
| 86 | |
| 87 | What if we modify our CA-mode system above with “warm spares”? We can |
| 88 | say that commits must go to all of the spares as well as the active |
| 89 | servers, but a loss of one active server requires that one warm spare |
| 90 |