Fossil SCM
Further edits to the fossil-v-git.wiki page.
Commit
7c32a7847cbcbfa0442330cea8832fc17356d3bf
Parent
ca891ab6c16e00a…
1 file changed
+9
-4
+9
-4
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | <title>Fossil Versus Git</title> |
| 2 | 2 | |
| 3 | 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | 4 | |
| 5 | 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | -it is [./inout.wiki | easy to change]. | |
| 6 | +you can easily [./inout.wiki | move your content]¹. | |
| 7 | 7 | |
| 8 | 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | 9 | but there are also important differences. |
| 10 | 10 | See the table below for |
| 11 | 11 | a high-level summary and the text that follows for more details. |
| @@ -13,10 +13,14 @@ | ||
| 13 | 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | 14 | so the information here |
| 15 | 15 | might be biased in favor of Fossil. Ask around with people who have |
| 16 | 16 | used both Fossil and Git for other opinions. |
| 17 | 17 | |
| 18 | +¹<small><i>Git does not support | |
| 19 | +wiki, tickets, or tech-notes, so those elements will not transfer when | |
| 20 | +exporting from Fossil to Git.</i></small> | |
| 21 | + | |
| 18 | 22 | <h2>2.0 Executive Summary:</h2> |
| 19 | 23 | |
| 20 | 24 | <blockquote><center><table border=1 cellpadding=5> |
| 21 | 25 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 22 | 26 | <tr><td>File versioning only</td> |
| @@ -67,27 +71,28 @@ | ||
| 67 | 71 | formatting details). Both systems store check-ins as immutable |
| 68 | 72 | objects referencing their immediate ancestors and named by their SHA1 hash. |
| 69 | 73 | |
| 70 | 74 | The difference is that Git stores its objects as individual files |
| 71 | 75 | in the ".git" folder or compressed into |
| 72 | -a bespoke "pack-files", whereas Fossil stores its objects in a | |
| 76 | +bespoke "pack-files", whereas Fossil stores its objects in a | |
| 73 | 77 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 74 | 78 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 75 | 79 | Fossil uses a proven, general-purpose SQL database. This |
| 76 | 80 | difference is more than an implementation detail. It |
| 77 | 81 | has important consequences. |
| 78 | 82 | |
| 79 | 83 | With Git, one can easily locate the ancestors of a particular check-in |
| 80 | -by following the pointers embedded the check-in object, but it is very | |
| 84 | +by following the pointers embedded the check-in object, but it is | |
| 81 | 85 | difficult to go the other direction and locate the descendants of a |
| 82 | 86 | check-in. It is so difficult, in fact, that neither native Git nor |
| 83 | 87 | GitHub provide this capability. With Git, if you are looking at some |
| 84 | 88 | historical check-in then you cannot ask |
| 85 | 89 | "what came next" or "what are the children of this check-in". |
| 86 | 90 | |
| 87 | 91 | Fossil, on the other hand, parses essential information about check-ins |
| 88 | -(such as parentage) into a relation database that can be easily | |
| 92 | +(parents, children, committers, comments, files changed, etc.) | |
| 93 | +into a relation database that can be easily | |
| 89 | 94 | queried using concise SQL statements to find both ancestors and |
| 90 | 95 | descendents of a check-in. |
| 91 | 96 | |
| 92 | 97 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 93 | 98 | difficult to locate and subject to garbage collection. This |
| 94 | 99 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Versus Git</title> |
| 2 | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | it is [./inout.wiki | easy to change]. |
| 7 | |
| 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | but there are also important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| @@ -13,10 +13,14 @@ | |
| 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | so the information here |
| 15 | might be biased in favor of Fossil. Ask around with people who have |
| 16 | used both Fossil and Git for other opinions. |
| 17 | |
| 18 | <h2>2.0 Executive Summary:</h2> |
| 19 | |
| 20 | <blockquote><center><table border=1 cellpadding=5> |
| 21 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 22 | <tr><td>File versioning only</td> |
| @@ -67,27 +71,28 @@ | |
| 67 | formatting details). Both systems store check-ins as immutable |
| 68 | objects referencing their immediate ancestors and named by their SHA1 hash. |
| 69 | |
| 70 | The difference is that Git stores its objects as individual files |
| 71 | in the ".git" folder or compressed into |
| 72 | a bespoke "pack-files", whereas Fossil stores its objects in a |
| 73 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 74 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 75 | Fossil uses a proven, general-purpose SQL database. This |
| 76 | difference is more than an implementation detail. It |
| 77 | has important consequences. |
| 78 | |
| 79 | With Git, one can easily locate the ancestors of a particular check-in |
| 80 | by following the pointers embedded the check-in object, but it is very |
| 81 | difficult to go the other direction and locate the descendants of a |
| 82 | check-in. It is so difficult, in fact, that neither native Git nor |
| 83 | GitHub provide this capability. With Git, if you are looking at some |
| 84 | historical check-in then you cannot ask |
| 85 | "what came next" or "what are the children of this check-in". |
| 86 | |
| 87 | Fossil, on the other hand, parses essential information about check-ins |
| 88 | (such as parentage) into a relation database that can be easily |
| 89 | queried using concise SQL statements to find both ancestors and |
| 90 | descendents of a check-in. |
| 91 | |
| 92 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 93 | difficult to locate and subject to garbage collection. This |
| 94 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Versus Git</title> |
| 2 | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | you can easily [./inout.wiki | move your content]¹. |
| 7 | |
| 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | but there are also important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| @@ -13,10 +13,14 @@ | |
| 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | so the information here |
| 15 | might be biased in favor of Fossil. Ask around with people who have |
| 16 | used both Fossil and Git for other opinions. |
| 17 | |
| 18 | ¹<small><i>Git does not support |
| 19 | wiki, tickets, or tech-notes, so those elements will not transfer when |
| 20 | exporting from Fossil to Git.</i></small> |
| 21 | |
| 22 | <h2>2.0 Executive Summary:</h2> |
| 23 | |
| 24 | <blockquote><center><table border=1 cellpadding=5> |
| 25 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 26 | <tr><td>File versioning only</td> |
| @@ -67,27 +71,28 @@ | |
| 71 | formatting details). Both systems store check-ins as immutable |
| 72 | objects referencing their immediate ancestors and named by their SHA1 hash. |
| 73 | |
| 74 | The difference is that Git stores its objects as individual files |
| 75 | in the ".git" folder or compressed into |
| 76 | bespoke "pack-files", whereas Fossil stores its objects in a |
| 77 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 78 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 79 | Fossil uses a proven, general-purpose SQL database. This |
| 80 | difference is more than an implementation detail. It |
| 81 | has important consequences. |
| 82 | |
| 83 | With Git, one can easily locate the ancestors of a particular check-in |
| 84 | by following the pointers embedded the check-in object, but it is |
| 85 | difficult to go the other direction and locate the descendants of a |
| 86 | check-in. It is so difficult, in fact, that neither native Git nor |
| 87 | GitHub provide this capability. With Git, if you are looking at some |
| 88 | historical check-in then you cannot ask |
| 89 | "what came next" or "what are the children of this check-in". |
| 90 | |
| 91 | Fossil, on the other hand, parses essential information about check-ins |
| 92 | (parents, children, committers, comments, files changed, etc.) |
| 93 | into a relation database that can be easily |
| 94 | queried using concise SQL statements to find both ancestors and |
| 95 | descendents of a check-in. |
| 96 | |
| 97 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 98 | difficult to locate and subject to garbage collection. This |
| 99 |