56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
-
+
|
If you clone Fossil's self-hosting repository, you get the entire
Fossil website - source code, documentation, ticket history, and so forth.
For developers who choose to self-host projects (rather than using a
3rd-party service such as GitHub) Fossil is much easier to set up, since
the stand-alone Fossil executable together with a 2-line CGI script
suffice to instantiate a full-featured developer website. To accomplish
the same using Git requires locating, installed, configuring, integrating,
the same using Git requires locating, installing, configuring, integrating,
and managing a wide assortment of separate tools. Standing up a developer
website using Fossil can be done in minutes, whereas doing the same using
Git requires hours or days.
<h3>3.2 Database</h3>
The baseline data structures for Fossil and Git are the same (modulo
|
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
-
+
|
check-in. It is so difficult, in fact, that neither native Git nor
GitHub provide this capability. With Git, if you are looking at some
historical check-in then you cannot ask
"what came next" or "what are the children of this check-in".
Fossil, on the other hand, parses essential information about check-ins
(parents, children, committers, comments, files changed, etc.)
into a relation database that can be easily
into a relational database that can be easily
queried using concise SQL statements to find both ancestors and
descendents of a check-in.
Leaf check-ins in Git that lack a "ref" become "detached", making them
difficult to locate and subject to garbage collection. This
"detached head" problem has caused untold grief for countless
Git users. With Fossil, all check-ins are easily located using
|