Fossil SCM

Documentation updates.

drh 2010-12-22 16:06 trunk

Commit c1c18b72245b63b6e7aeb25adb8249c41d73dd12

Parent e685fc0b858596f…

5 files changed +21 -7 +8 -6 +12 -2 +2 -1 +39 -20

~ www/branching.wiki ~ www/checkin_names.wiki ~ www/fossil-v-git.wiki ~ www/index.wiki ~ www/quickstart.wiki

M www/branching.wiki

+21 -7

		--- www/branching.wiki
		+++ www/branching.wiki
		@@ -24,12 +24,18 @@
24	24	and that 1 is a <i>parent</i> of 2.
25	25	Check-in 3 is derived from check-in 2, making
26	26	3 a child of 2. We say that 3 is a <i>descendant</i> of both 1 and 2 and that 1
27	27	and 2 are both <i>ancestors</i> of 3.
28	28
29		-We call the graph of check-ins a <i>tree</i>. Check-in 1 is the <i>root</i>
30		-since it has no ancestors. Check-in 4 is a <i>leaf</i> of the tree since
	29	+<a name="dag"></a>
	30	+<h2>DAGs</h2>
	31	+
	32	+The graph of check-ins is a
	33	+[http://en.wikipedia.org/wiki/Directed_acyclic_graph \| directed acyclic graph]
	34	+and so we will
	35	+henceforth call it a <i>DAG</i>. Check-in 1 is the <i>root</i> of the DAG
	36	+since it has no ancestors. Check-in 4 is a <i>leaf</i> of the DAG since
31	37	it has no descendants. (We will give a more precise in the definition of
32	38	"leaf" later.)
33	39
34	40	Alas, reality often interferes with the simple linear development of a
35	41	project. Suppose two programmers make independent modifications to check-in 2.
		@@ -53,28 +59,28 @@
53	59	abort Bob's commit attempt with a message "would fork". This allows Bob
54	60	to do a "fossil update" which would pull in Alice's changes and merge them
55	61	together with his own changes. After merging, Bob could then commit
56	62	check-in 4 as a child of check-in 3 and the result would be a linear graph
57	63	as shown in figure 1. This is how CVS works. This is also how fossil
58		-works in "autosync" mode.
	64	+works in [concepts.wiki#workflow \| "autosync"] mode.
59	65
60	66	But it might be that Bob is off-network when he does his commit, so he
61	67	has no way of knowing that Alice has already committed her changes.
62	68	Or, it could be that Bob has turned off "autosync" mode in Fossil. Or,
63	69	maybe Bob just doesn't want to merge in Alice's changes before he has
64	70	saved his own, so he forces the commit to occur using the "--force" option
65	71	to the fossil <b>commit</b> command. For whatever reason, two commits against
66		-check-in 2 have occurred and now the tree has two leaves.
	72	+check-in 2 have occurred and now the DAG has two leaves.
67	73
68	74	So which version of the project is the "latest" in the sense of having
69	75	the most features and the most bug fixes? When there is more than
70	76	one leaf in the graph, you don't really know. So we like to have
71	77	graphs with a single leaf.
72	78
73	79	To resolve this situation, Alice can use the fossil <b>merge</b> command
74	80	to merge in Bob's changes in her local copy of check-in 3. Then she
75		-can commit the results as check-in 5. This results in a tree as shown
	81	+can commit the results as check-in 5. This results in a DAG as shown
76	82	in figure 3.
77	83
78	84	<center><table border=1 cellpadding=10 hspace=10 vspace=10>
79	85	<tr><td align="center">
80	86	<img src="branch03.gif" width=282 height=152><br>
		@@ -108,11 +114,11 @@
108	114	instead of as a separate manual step. We will not take sides in that
109	115	debate. We will simply point out that fossil enables you to do it either way.
110	116
111	117	<h2>Forking Versus Branching</h2>
112	118
113		-Having more than one leaf in the check-in tree is usually
	119	+Having more than one leaf in the check-in DAG is usually
114	120	considered undesirable, and so forks are usually either avoided entirely,
115	121	as in figure 1, or else quickly resolved as shown in figure 3.
116	122	But sometimes, one does want to have multiple leaves. For example, a project
117	123	might have one leaf that is the latest version of the project under
118	124	development and another leaf that is the latest version that has been
		@@ -232,11 +238,11 @@
232	238
233	239
234	240	<blockquote><dl>
235	241	<dt><b>Branch</b></dt>
236	242	<dd><p>A branch is a set of check-ins that have the same value for their
237		-branch property.</p></dd>
	243	+"branch" property.</p></dd>
238	244	<dt><b>Leaf</b></dt>
239	245	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
240	246	<dt><b>Closed Leaf</b></dt>
241	247	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
242	248	are intented to never be extended with descendants and hence are omitted
		@@ -259,5 +265,13 @@
259	265
260	266	Check-in 2 of figure 3 is considered a "fork"
261	267	because it has two children in the same branch. Check-in 2 of figure 5
262	268	also has two children, but each child is in a different branch, hence in
263	269	figure 5, check-in 2 is considered a "branch point".
	270	+
	271	+<h2>Differences With Other DVCSes</h2>
	272	+
	273	+Fossil keeps all check-ins on a single DAG. Branches are identified with
	274	+tags. This means that check-ins can be freely moved between branches
	275	+simply by altering the tags.
	276	+
	277	+Most other DVCSes maintain a separate DAG for each branch.
264	278

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -24,12 +24,18 @@
24	and that 1 is a <i>parent</i> of 2.
25	Check-in 3 is derived from check-in 2, making
26	3 a child of 2. We say that 3 is a <i>descendant</i> of both 1 and 2 and that 1
27	and 2 are both <i>ancestors</i> of 3.
28
29	We call the graph of check-ins a <i>tree</i>. Check-in 1 is the <i>root</i>
30	since it has no ancestors. Check-in 4 is a <i>leaf</i> of the tree since






31	it has no descendants. (We will give a more precise in the definition of
32	"leaf" later.)
33
34	Alas, reality often interferes with the simple linear development of a
35	project. Suppose two programmers make independent modifications to check-in 2.
	@@ -53,28 +59,28 @@
53	abort Bob's commit attempt with a message "would fork". This allows Bob
54	to do a "fossil update" which would pull in Alice's changes and merge them
55	together with his own changes. After merging, Bob could then commit
56	check-in 4 as a child of check-in 3 and the result would be a linear graph
57	as shown in figure 1. This is how CVS works. This is also how fossil
58	works in "autosync" mode.
59
60	But it might be that Bob is off-network when he does his commit, so he
61	has no way of knowing that Alice has already committed her changes.
62	Or, it could be that Bob has turned off "autosync" mode in Fossil. Or,
63	maybe Bob just doesn't want to merge in Alice's changes before he has
64	saved his own, so he forces the commit to occur using the "--force" option
65	to the fossil <b>commit</b> command. For whatever reason, two commits against
66	check-in 2 have occurred and now the tree has two leaves.
67
68	So which version of the project is the "latest" in the sense of having
69	the most features and the most bug fixes? When there is more than
70	one leaf in the graph, you don't really know. So we like to have
71	graphs with a single leaf.
72
73	To resolve this situation, Alice can use the fossil <b>merge</b> command
74	to merge in Bob's changes in her local copy of check-in 3. Then she
75	can commit the results as check-in 5. This results in a tree as shown
76	in figure 3.
77
78	<center><table border=1 cellpadding=10 hspace=10 vspace=10>
79	<tr><td align="center">
80	<img src="branch03.gif" width=282 height=152><br>
	@@ -108,11 +114,11 @@
108	instead of as a separate manual step. We will not take sides in that
109	debate. We will simply point out that fossil enables you to do it either way.
110
111	<h2>Forking Versus Branching</h2>
112
113	Having more than one leaf in the check-in tree is usually
114	considered undesirable, and so forks are usually either avoided entirely,
115	as in figure 1, or else quickly resolved as shown in figure 3.
116	But sometimes, one does want to have multiple leaves. For example, a project
117	might have one leaf that is the latest version of the project under
118	development and another leaf that is the latest version that has been
	@@ -232,11 +238,11 @@
232
233
234	<blockquote><dl>
235	<dt><b>Branch</b></dt>
236	<dd><p>A branch is a set of check-ins that have the same value for their
237	branch property.</p></dd>
238	<dt><b>Leaf</b></dt>
239	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
240	<dt><b>Closed Leaf</b></dt>
241	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
242	are intented to never be extended with descendants and hence are omitted
	@@ -259,5 +265,13 @@
259
260	Check-in 2 of figure 3 is considered a "fork"
261	because it has two children in the same branch. Check-in 2 of figure 5
262	also has two children, but each child is in a different branch, hence in
263	figure 5, check-in 2 is considered a "branch point".








264

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -24,12 +24,18 @@
24	and that 1 is a <i>parent</i> of 2.
25	Check-in 3 is derived from check-in 2, making
26	3 a child of 2. We say that 3 is a <i>descendant</i> of both 1 and 2 and that 1
27	and 2 are both <i>ancestors</i> of 3.
28
29	<a name="dag"></a>
30	<h2>DAGs</h2>
31
32	The graph of check-ins is a
33	[http://en.wikipedia.org/wiki/Directed_acyclic_graph \| directed acyclic graph]
34	and so we will
35	henceforth call it a <i>DAG</i>. Check-in 1 is the <i>root</i> of the DAG
36	since it has no ancestors. Check-in 4 is a <i>leaf</i> of the DAG since
37	it has no descendants. (We will give a more precise in the definition of
38	"leaf" later.)
39
40	Alas, reality often interferes with the simple linear development of a
41	project. Suppose two programmers make independent modifications to check-in 2.
	@@ -53,28 +59,28 @@
59	abort Bob's commit attempt with a message "would fork". This allows Bob
60	to do a "fossil update" which would pull in Alice's changes and merge them
61	together with his own changes. After merging, Bob could then commit
62	check-in 4 as a child of check-in 3 and the result would be a linear graph
63	as shown in figure 1. This is how CVS works. This is also how fossil
64	works in [concepts.wiki#workflow \| "autosync"] mode.
65
66	But it might be that Bob is off-network when he does his commit, so he
67	has no way of knowing that Alice has already committed her changes.
68	Or, it could be that Bob has turned off "autosync" mode in Fossil. Or,
69	maybe Bob just doesn't want to merge in Alice's changes before he has
70	saved his own, so he forces the commit to occur using the "--force" option
71	to the fossil <b>commit</b> command. For whatever reason, two commits against
72	check-in 2 have occurred and now the DAG has two leaves.
73
74	So which version of the project is the "latest" in the sense of having
75	the most features and the most bug fixes? When there is more than
76	one leaf in the graph, you don't really know. So we like to have
77	graphs with a single leaf.
78
79	To resolve this situation, Alice can use the fossil <b>merge</b> command
80	to merge in Bob's changes in her local copy of check-in 3. Then she
81	can commit the results as check-in 5. This results in a DAG as shown
82	in figure 3.
83
84	<center><table border=1 cellpadding=10 hspace=10 vspace=10>
85	<tr><td align="center">
86	<img src="branch03.gif" width=282 height=152><br>
	@@ -108,11 +114,11 @@
114	instead of as a separate manual step. We will not take sides in that
115	debate. We will simply point out that fossil enables you to do it either way.
116
117	<h2>Forking Versus Branching</h2>
118
119	Having more than one leaf in the check-in DAG is usually
120	considered undesirable, and so forks are usually either avoided entirely,
121	as in figure 1, or else quickly resolved as shown in figure 3.
122	But sometimes, one does want to have multiple leaves. For example, a project
123	might have one leaf that is the latest version of the project under
124	development and another leaf that is the latest version that has been
	@@ -232,11 +238,11 @@
238
239
240	<blockquote><dl>
241	<dt><b>Branch</b></dt>
242	<dd><p>A branch is a set of check-ins that have the same value for their
243	"branch" property.</p></dd>
244	<dt><b>Leaf</b></dt>
245	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
246	<dt><b>Closed Leaf</b></dt>
247	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
248	are intented to never be extended with descendants and hence are omitted
	@@ -259,5 +265,13 @@
265
266	Check-in 2 of figure 3 is considered a "fork"
267	because it has two children in the same branch. Check-in 2 of figure 5
268	also has two children, but each child is in a different branch, hence in
269	figure 5, check-in 2 is considered a "branch point".
270
271	<h2>Differences With Other DVCSes</h2>
272
273	Fossil keeps all check-ins on a single DAG. Branches are identified with
274	tags. This means that check-ins can be freely moved between branches
275	simply by altering the tags.
276
277	Most other DVCSes maintain a separate DAG for each branch.
278

M www/checkin_names.wiki

+8 -6

		--- www/checkin_names.wiki
		+++ www/checkin_names.wiki
		@@ -31,11 +31,11 @@
31	31	<blockquote><pre>
32	32	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
33	33	</pre></blockquote>
34	34
35	35	The full 40-character SHA1 hash is unwieldy to remember and type, though,
36		-os Fossil also accepts a unique prefix of the hash, using any combination
	36	+so Fossil also accepts a unique prefix of the hash, using any combination
37	37	of upper and lower case letters, as long as the prefix is at least 4
38	38	characters long. Hence the following commands all
39	39	accomplish the same thing as the above:
40	40
41	41	<blockquote><pre>
		@@ -83,17 +83,19 @@
83	83	Note also that there can (in theory) be an ambiguity between tag names
84	84	and canonical names. Suppose, for example, you had a check-in with
85	85	the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you
86	86	also happened to have tagged a different check-in with "deed2". If
87	87	you use the "deed2" name, does it choose the canonical name or the tag
88		-name? In such cases, you can prefix the tag name with "tag:". Hence
	88	+name? In such cases, you can prefix the tag name with "tag:".
	89	+For example:
89	90
90		-<blockquote>
	91	+<blockquote><tt>
91	92	fossil info tag:deed2
92		-</blockquote>
	93	+</tt></blockquote>
93	94
94		-Will refer to the most recent check-in tagged with "deed2" not to the
	95	+The "tag:deed2" name will refer to the most recent check-in
	96	+tagged with "deed2" not to the
95	97	check-in whose canonical name begins with "deed2".
96	98
97	99	<h2>Timestamps</h2>
98	100
99	101	A timestamp in one of the formats shown below means the most recent
		@@ -103,11 +105,11 @@
103	105	* <i>YYYY-MM-DD HH:MM</i>
104	106	* <i>YYYY-MM-DD HH:MM:SS</i>
105	107
106	108	The space between the day and the year can optionally be
107	109	replaced by an uppercase <b>T</b> and the entire timestamp can
108		-optinally be followed by "<b>utc</b>".
	110	+optionally be followed by "<b>utc</b>".
109	111
110	112	In its default configuration, Fossil interprets and displays all dates
111	113	in Universal Coordinated Time (UTC). This tends to work the best for
112	114	distributed projects where participants are scattered around the globe.
113	115	But there is an open on the Admin/Timeline page of the web-interface to
114	116

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -31,11 +31,11 @@
31	<blockquote><pre>
32	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
33	</pre></blockquote>
34
35	The full 40-character SHA1 hash is unwieldy to remember and type, though,
36	os Fossil also accepts a unique prefix of the hash, using any combination
37	of upper and lower case letters, as long as the prefix is at least 4
38	characters long. Hence the following commands all
39	accomplish the same thing as the above:
40
41	<blockquote><pre>
	@@ -83,17 +83,19 @@
83	Note also that there can (in theory) be an ambiguity between tag names
84	and canonical names. Suppose, for example, you had a check-in with
85	the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you
86	also happened to have tagged a different check-in with "deed2". If
87	you use the "deed2" name, does it choose the canonical name or the tag
88	name? In such cases, you can prefix the tag name with "tag:". Hence

89
90	<blockquote>
91	fossil info tag:deed2
92	</blockquote>
93
94	Will refer to the most recent check-in tagged with "deed2" not to the

95	check-in whose canonical name begins with "deed2".
96
97	<h2>Timestamps</h2>
98
99	A timestamp in one of the formats shown below means the most recent
	@@ -103,11 +105,11 @@
103	* <i>YYYY-MM-DD HH:MM</i>
104	* <i>YYYY-MM-DD HH:MM:SS</i>
105
106	The space between the day and the year can optionally be
107	replaced by an uppercase <b>T</b> and the entire timestamp can
108	optinally be followed by "<b>utc</b>".
109
110	In its default configuration, Fossil interprets and displays all dates
111	in Universal Coordinated Time (UTC). This tends to work the best for
112	distributed projects where participants are scattered around the globe.
113	But there is an open on the Admin/Timeline page of the web-interface to
114

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -31,11 +31,11 @@
31	<blockquote><pre>
32	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
33	</pre></blockquote>
34
35	The full 40-character SHA1 hash is unwieldy to remember and type, though,
36	so Fossil also accepts a unique prefix of the hash, using any combination
37	of upper and lower case letters, as long as the prefix is at least 4
38	characters long. Hence the following commands all
39	accomplish the same thing as the above:
40
41	<blockquote><pre>
	@@ -83,17 +83,19 @@
83	Note also that there can (in theory) be an ambiguity between tag names
84	and canonical names. Suppose, for example, you had a check-in with
85	the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you
86	also happened to have tagged a different check-in with "deed2". If
87	you use the "deed2" name, does it choose the canonical name or the tag
88	name? In such cases, you can prefix the tag name with "tag:".
89	For example:
90
91	<blockquote><tt>
92	fossil info tag:deed2
93	</tt></blockquote>
94
95	The "tag:deed2" name will refer to the most recent check-in
96	tagged with "deed2" not to the
97	check-in whose canonical name begins with "deed2".
98
99	<h2>Timestamps</h2>
100
101	A timestamp in one of the formats shown below means the most recent
	@@ -103,11 +105,11 @@
105	* <i>YYYY-MM-DD HH:MM</i>
106	* <i>YYYY-MM-DD HH:MM:SS</i>
107
108	The space between the day and the year can optionally be
109	replaced by an uppercase <b>T</b> and the entire timestamp can
110	optionally be followed by "<b>utc</b>".
111
112	In its default configuration, Fossil interprets and displays all dates
113	in Universal Coordinated Time (UTC). This tends to work the best for
114	distributed projects where participants are scattered around the globe.
115	But there is an open on the Admin/Timeline page of the web-interface to
116

M www/fossil-v-git.wiki

+12 -2

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -25,10 +25,12 @@
25	25	<tr><td>Complex</td><td>Intuitive</td></tr>
26	26	<tr><td>Separate web tools</td><td>Integrated Web interface</td></tr>
27	27	<tr><td>Lots of little tools</td><td>Single executable</td></tr>
28	28	<tr><td>Pile-of-files repository</td><td>Single file repository</td></tr>
29	29	<tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr>
	30	+<tr><td>Multiple [./branching.wiki#dag \| DAGs]; one per branch</td>
	31	+ <td>All branches on one [./branching.wiki#dag \| DAG]</td></tr>
30	32	<tr><td>GPL</td><td>BSD</td></tr>
31	33	</table></center></blockquote>
32	34
33	35	<h2>3.0 Discussion</h2>
34	36
		@@ -184,20 +186,28 @@
184	186	[http://en.wikipedia.org/wiki/Winston_Smith \| Winston Smith] did for
185	187	a living in Orwell's novel
186	188	[http://en.wikipedia.org/wiki/Nineteen_Eighty-Four \| 1984].
187	189
188	190	Fossil deliberately avoids rewriting history. Fossil strives to follow
189		-the accounting philosophy of never erasing anything. Mistakes are fixed
	191	+the accountants philosophy of never erasing anything. Mistakes are fixed
190	192	by entering a correction, with an explanation of why the correction is
191	193	needed. This can make the history of a project messy, but it also
192	194	makes it more honest. The lack of a "rebase" function is considered
193	195	a feature of Fossil, not a bug.
194	196
195		-<h3>3.9 License</h3>
	197	+<h3>3.9 Single DAG</h3>
	198	+
	199	+Git maintains a separate directed acyclic graph (DAG) for each branch
	200	+of a repository. Fossil maintains a single DAG for all branches. In
	201	+Git, the branch that a specific check-in belongs to is determined by
	202	+which DAG it is part of. In Fossil, the branch of a check-in is determined
	203	+by [./branching.wiki#tags \| tags and properties] attached to the check-in.
	204	+
	205	+<h3>3.10 License</h3>
196	206
197	207	Both Git and Fossil are open-source. Git is under
198	208	[http://www.gnu.org/licenses/gpl.html \| GPL] whereas Fossil is
199	209	under the
200	210	[http://en.wikipedia.org/wiki/BSD_licenses \| two-clause BSD license].
201	211	The difference should not be of a concern to most users. However,
202	212	some corporate lawyers have objections to using GPL products and
203	213	are more comfortable with a BSD-style license.
204	214

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -25,10 +25,12 @@
25	<tr><td>Complex</td><td>Intuitive</td></tr>
26	<tr><td>Separate web tools</td><td>Integrated Web interface</td></tr>
27	<tr><td>Lots of little tools</td><td>Single executable</td></tr>
28	<tr><td>Pile-of-files repository</td><td>Single file repository</td></tr>
29	<tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr>


30	<tr><td>GPL</td><td>BSD</td></tr>
31	</table></center></blockquote>
32
33	<h2>3.0 Discussion</h2>
34
	@@ -184,20 +186,28 @@
184	[http://en.wikipedia.org/wiki/Winston_Smith \| Winston Smith] did for
185	a living in Orwell's novel
186	[http://en.wikipedia.org/wiki/Nineteen_Eighty-Four \| 1984].
187
188	Fossil deliberately avoids rewriting history. Fossil strives to follow
189	the accounting philosophy of never erasing anything. Mistakes are fixed
190	by entering a correction, with an explanation of why the correction is
191	needed. This can make the history of a project messy, but it also
192	makes it more honest. The lack of a "rebase" function is considered
193	a feature of Fossil, not a bug.
194
195	<h3>3.9 License</h3>








196
197	Both Git and Fossil are open-source. Git is under
198	[http://www.gnu.org/licenses/gpl.html \| GPL] whereas Fossil is
199	under the
200	[http://en.wikipedia.org/wiki/BSD_licenses \| two-clause BSD license].
201	The difference should not be of a concern to most users. However,
202	some corporate lawyers have objections to using GPL products and
203	are more comfortable with a BSD-style license.
204

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -25,10 +25,12 @@
25	<tr><td>Complex</td><td>Intuitive</td></tr>
26	<tr><td>Separate web tools</td><td>Integrated Web interface</td></tr>
27	<tr><td>Lots of little tools</td><td>Single executable</td></tr>
28	<tr><td>Pile-of-files repository</td><td>Single file repository</td></tr>
29	<tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr>
30	<tr><td>Multiple [./branching.wiki#dag \| DAGs]; one per branch</td>
31	<td>All branches on one [./branching.wiki#dag \| DAG]</td></tr>
32	<tr><td>GPL</td><td>BSD</td></tr>
33	</table></center></blockquote>
34
35	<h2>3.0 Discussion</h2>
36
	@@ -184,20 +186,28 @@
186	[http://en.wikipedia.org/wiki/Winston_Smith \| Winston Smith] did for
187	a living in Orwell's novel
188	[http://en.wikipedia.org/wiki/Nineteen_Eighty-Four \| 1984].
189
190	Fossil deliberately avoids rewriting history. Fossil strives to follow
191	the accountants philosophy of never erasing anything. Mistakes are fixed
192	by entering a correction, with an explanation of why the correction is
193	needed. This can make the history of a project messy, but it also
194	makes it more honest. The lack of a "rebase" function is considered
195	a feature of Fossil, not a bug.
196
197	<h3>3.9 Single DAG</h3>
198
199	Git maintains a separate directed acyclic graph (DAG) for each branch
200	of a repository. Fossil maintains a single DAG for all branches. In
201	Git, the branch that a specific check-in belongs to is determined by
202	which DAG it is part of. In Fossil, the branch of a check-in is determined
203	by [./branching.wiki#tags \| tags and properties] attached to the check-in.
204
205	<h3>3.10 License</h3>
206
207	Both Git and Fossil are open-source. Git is under
208	[http://www.gnu.org/licenses/gpl.html \| GPL] whereas Fossil is
209	under the
210	[http://en.wikipedia.org/wiki/BSD_licenses \| two-clause BSD license].
211	The difference should not be of a concern to most users. However,
212	some corporate lawyers have objections to using GPL products and
213	are more comfortable with a BSD-style license.
214

M www/index.wiki

+2 -1

		--- www/index.wiki
		+++ www/index.wiki
		@@ -51,11 +51,12 @@
51	51	2. <b>Web Interface</b> -
52	52	Fossil has a built-in and easy-to-use [./webui.wiki \| web interface]
53	53	that simplifies project tracking and promotes situational awareness.
54	54	Simply type "fossil ui" from within any check-out and Fossil
55	55	automatically opens your web browser in a page that gives detailed
56		- history and status information on that project.
	56	+ [/timeline?n=100&y=ci \| graphical history] and status information
	57	+ on that project.
57	58
58	59	3. <b>Autosync</b> -
59	60	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
60	61	which helps to keep projects moving
61	62	forward by reducing the amount of needless
62	63

	--- www/index.wiki
	+++ www/index.wiki
	@@ -51,11 +51,12 @@
51	2. <b>Web Interface</b> -
52	Fossil has a built-in and easy-to-use [./webui.wiki \| web interface]
53	that simplifies project tracking and promotes situational awareness.
54	Simply type "fossil ui" from within any check-out and Fossil
55	automatically opens your web browser in a page that gives detailed
56	history and status information on that project.

57
58	3. <b>Autosync</b> -
59	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
60	which helps to keep projects moving
61	forward by reducing the amount of needless
62

	--- www/index.wiki
	+++ www/index.wiki
	@@ -51,11 +51,12 @@
51	2. <b>Web Interface</b> -
52	Fossil has a built-in and easy-to-use [./webui.wiki \| web interface]
53	that simplifies project tracking and promotes situational awareness.
54	Simply type "fossil ui" from within any check-out and Fossil
55	automatically opens your web browser in a page that gives detailed
56	[/timeline?n=100&y=ci \| graphical history] and status information
57	on that project.
58
59	3. <b>Autosync</b> -
60	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
61	which helps to keep projects moving
62	forward by reducing the amount of needless
63

M www/quickstart.wiki

+39 -20

		--- www/quickstart.wiki
		+++ www/quickstart.wiki
		@@ -110,12 +110,12 @@
110	110
111	111	<blockquote>
112	112	<b>fossil info</b><br>
113	113	<b>fossil status</b><br>
114	114	<b>fossil changes</b><br>
	115	+ <b>fossil diff</b><br>
115	116	<b>fossil timeline</b><br>
116		- <b>fossil leaves</b><br>
117	117	<b>fossil ls</b><br>
118	118	<b>fossil branch list</b><br>
119	119	</blockquote>
120	120
121	121	</blockquote><h2>Configuring Your Local Repository</h2><blockquote>
		@@ -127,12 +127,12 @@
127	127
128	128	<blockquote>
129	129	<b>fossil ui </b><i> repository-filename</i>
130	130	</blockquote>
131	131
132		- <p>(Note that this requires you to have checked out a local tree
133		- beforehand.)</p>
	132	+ <p>You can omit the <i>repository-filename</i> from the command above
	133	+ if you are inside a checked-out local tree.</p>
134	134
135	135	<p>This starts a web server then automatically launches your
136	136	web browser and makes it point to this web server. If your system
137	137	has an unusual configuration, fossil might not be able to figure out
138	138	how to start your web browser. In that case, first tell fossil
		@@ -165,14 +165,11 @@
165	165	<blockquote>
166	166	<b>fossil commit</b>
167	167	</blockquote>
168	168
169	169	<p>You will be prompted for check-in comments using whatever editor
170		- is specified by your VISUAL or EDITOR environment variable. If you
171		- have GPG installed, you may be prompted for your GPG passphrase so
172		- that the check-in can be signed with your GPG signature. After
173		- this your changes will be checked in.</p>
	170	+ is specified by your VISUAL or EDITOR environment variable.</p>
174	171
175	172	</blockquote><h2>Sharing Changes</h2><blockquote>
176	173
177	174	<p>The changes you <b>commit</b> are only on your local repository.
178	175	To share those changes with other repositories, do:</p>
		@@ -197,36 +194,58 @@
197	194	<p>When you pull in changes from others, they go into your repository,
198	195	not into your checked-out local tree. To get the changes into your
199	196	local tree, use <b>update</b>:</p>
200	197
201	198	<blockquote>
202		- <b>fossil update</b> <i>AID</i>
	199	+ <b>fossil update</b> <i>VERSION</i>
203	200	</blockquote>
204	201
205		- <p>The <i>AID</i> is some unique abbreviation to the 40-character
206		- artifact identifier (AID) for a particular check-in. If you omit
207		- the <i>AID</i> fossil moves you to the
208		- leaf version of the branch your are currently on. If your branch
209		- has multiple leaves, you get an error - you'll have to specify the
210		- leaf you want using a <i>AID</i> argument.</p>
	202	+ <p>The <i>VERSION</i> can be the name of a branch or tag or any
	203	+ abbreviation to the 40-character
	204	+ artifact identifier for a particular check-in, or it can be a
	205	+ date/time stamp. (<a href="./checkin_names.wiki">More information</a>.)
	206	+ If you omit
	207	+ the <i>VERSION</i>, then fossil moves you to the
	208	+ latest version of the branch your are currently on.</p>
211	209
212	210	</blockquote><h2>Branching And Merging</h2><blockquote>
213	211
214	212	<p>You can create branches by doing multiple commits off of the
215	213	same base version. To merge to branches back together, first
216	214	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
217	215	of the leaf of the other branch:</p>
218	216
219	217	<blockquote>
220		- <b>fossil merge</b> <i>AID</i>
	218	+ <b>fossil merge</b> <i>VERSION</i>
	219	+ </blockquote>
	220	+
	221	+ <p>The <i>VERSION</i> can be any of the forms allowed for <b>update</b>.
	222	+ After performing the merge, you will normally want to test it to
	223	+ make sure it does not break anything, then
	224	+ <b>commit</b> your chagnes. In the default configuration, the <b>commit</b>
	225	+ command will also automatically <b>push</b> your changes, but that
	226	+ feature can be disabled. (More information about
	227	+ <a href="concepts.wiki#workflow">autosync</a> and how to disable it.)
	228	+ Remember that your coworkers can not see your changes until you
	229	+ <b>commit</b> and <b>push</b> them.</p>
	230	+
	231	+ <p>The merge command has options to cherrypick individual
	232	+ changes, or to back out individual changes.</p>
	233	+
	234	+ <p>If a merge or update doesn't work out (perhaps something breaks or
	235	+ there are many merge conflicts) then you back up using:</p>
	236	+
	237	+ <blockquote>
	238	+ <b>fossil undo</b>
221	239	</blockquote>
222	240
223		- <p>Test to make sure your merge didn't mess up the code, then
224		- <b>commit</b> and possibly also <b>push</b> your changes. Remember
225		- that nobody else can see your changes until you <b>commit</b> and
226		- if other are using a different repository you will also need to
227		- <b>push</b>.</p>
	241	+ <p>This will back out the changes that the merge or update made to the
	242	+ working checkout. There is also a <b>redo</b> command if you undo by
	243	+ mistake. Undo and redo only work for changes that have
	244	+ not yet been checked in using <b>commit</b> and there is only a single
	245	+ level of undo/redo.</p>
	246	+
228	247
229	248	<a name="serversetup"></a>
230	249	</blockquote><h2>Setting Up A Server</h2><blockquote>
231	250
232	251	<p>The easiest way to set up a server is:</p>
233	252

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -110,12 +110,12 @@
110
111	<blockquote>
112	<b>fossil info</b><br>
113	<b>fossil status</b><br>
114	<b>fossil changes</b><br>

115	<b>fossil timeline</b><br>
116	<b>fossil leaves</b><br>
117	<b>fossil ls</b><br>
118	<b>fossil branch list</b><br>
119	</blockquote>
120
121	</blockquote><h2>Configuring Your Local Repository</h2><blockquote>
	@@ -127,12 +127,12 @@
127
128	<blockquote>
129	<b>fossil ui </b><i> repository-filename</i>
130	</blockquote>
131
132	<p>(Note that this requires you to have checked out a local tree
133	beforehand.)</p>
134
135	<p>This starts a web server then automatically launches your
136	web browser and makes it point to this web server. If your system
137	has an unusual configuration, fossil might not be able to figure out
138	how to start your web browser. In that case, first tell fossil
	@@ -165,14 +165,11 @@
165	<blockquote>
166	<b>fossil commit</b>
167	</blockquote>
168
169	<p>You will be prompted for check-in comments using whatever editor
170	is specified by your VISUAL or EDITOR environment variable. If you
171	have GPG installed, you may be prompted for your GPG passphrase so
172	that the check-in can be signed with your GPG signature. After
173	this your changes will be checked in.</p>
174
175	</blockquote><h2>Sharing Changes</h2><blockquote>
176
177	<p>The changes you <b>commit</b> are only on your local repository.
178	To share those changes with other repositories, do:</p>
	@@ -197,36 +194,58 @@
197	<p>When you pull in changes from others, they go into your repository,
198	not into your checked-out local tree. To get the changes into your
199	local tree, use <b>update</b>:</p>
200
201	<blockquote>
202	<b>fossil update</b> <i>AID</i>
203	</blockquote>
204
205	<p>The <i>AID</i> is some unique abbreviation to the 40-character
206	artifact identifier (AID) for a particular check-in. If you omit
207	the <i>AID</i> fossil moves you to the
208	leaf version of the branch your are currently on. If your branch
209	has multiple leaves, you get an error - you'll have to specify the
210	leaf you want using a <i>AID</i> argument.</p>

211
212	</blockquote><h2>Branching And Merging</h2><blockquote>
213
214	<p>You can create branches by doing multiple commits off of the
215	same base version. To merge to branches back together, first
216	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
217	of the leaf of the other branch:</p>
218
219	<blockquote>
220	<b>fossil merge</b> <i>AID</i>




















221	</blockquote>
222
223	<p>Test to make sure your merge didn't mess up the code, then
224	<b>commit</b> and possibly also <b>push</b> your changes. Remember
225	that nobody else can see your changes until you <b>commit</b> and
226	if other are using a different repository you will also need to
227	<b>push</b>.</p>

228
229	<a name="serversetup"></a>
230	</blockquote><h2>Setting Up A Server</h2><blockquote>
231
232	<p>The easiest way to set up a server is:</p>
233

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -110,12 +110,12 @@
110
111	<blockquote>
112	<b>fossil info</b><br>
113	<b>fossil status</b><br>
114	<b>fossil changes</b><br>
115	<b>fossil diff</b><br>
116	<b>fossil timeline</b><br>

117	<b>fossil ls</b><br>
118	<b>fossil branch list</b><br>
119	</blockquote>
120
121	</blockquote><h2>Configuring Your Local Repository</h2><blockquote>
	@@ -127,12 +127,12 @@
127
128	<blockquote>
129	<b>fossil ui </b><i> repository-filename</i>
130	</blockquote>
131
132	<p>You can omit the <i>repository-filename</i> from the command above
133	if you are inside a checked-out local tree.</p>
134
135	<p>This starts a web server then automatically launches your
136	web browser and makes it point to this web server. If your system
137	has an unusual configuration, fossil might not be able to figure out
138	how to start your web browser. In that case, first tell fossil
	@@ -165,14 +165,11 @@
165	<blockquote>
166	<b>fossil commit</b>
167	</blockquote>
168
169	<p>You will be prompted for check-in comments using whatever editor
170	is specified by your VISUAL or EDITOR environment variable.</p>



171
172	</blockquote><h2>Sharing Changes</h2><blockquote>
173
174	<p>The changes you <b>commit</b> are only on your local repository.
175	To share those changes with other repositories, do:</p>
	@@ -197,36 +194,58 @@
194	<p>When you pull in changes from others, they go into your repository,
195	not into your checked-out local tree. To get the changes into your
196	local tree, use <b>update</b>:</p>
197
198	<blockquote>
199	<b>fossil update</b> <i>VERSION</i>
200	</blockquote>
201
202	<p>The <i>VERSION</i> can be the name of a branch or tag or any
203	abbreviation to the 40-character
204	artifact identifier for a particular check-in, or it can be a
205	date/time stamp. (<a href="./checkin_names.wiki">More information</a>.)
206	If you omit
207	the <i>VERSION</i>, then fossil moves you to the
208	latest version of the branch your are currently on.</p>
209
210	</blockquote><h2>Branching And Merging</h2><blockquote>
211
212	<p>You can create branches by doing multiple commits off of the
213	same base version. To merge to branches back together, first
214	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
215	of the leaf of the other branch:</p>
216
217	<blockquote>
218	<b>fossil merge</b> <i>VERSION</i>
219	</blockquote>
220
221	<p>The <i>VERSION</i> can be any of the forms allowed for <b>update</b>.
222	After performing the merge, you will normally want to test it to
223	make sure it does not break anything, then
224	<b>commit</b> your chagnes. In the default configuration, the <b>commit</b>
225	command will also automatically <b>push</b> your changes, but that
226	feature can be disabled. (More information about
227	<a href="concepts.wiki#workflow">autosync</a> and how to disable it.)
228	Remember that your coworkers can not see your changes until you
229	<b>commit</b> and <b>push</b> them.</p>
230
231	<p>The merge command has options to cherrypick individual
232	changes, or to back out individual changes.</p>
233
234	<p>If a merge or update doesn't work out (perhaps something breaks or
235	there are many merge conflicts) then you back up using:</p>
236
237	<blockquote>
238	<b>fossil undo</b>
239	</blockquote>
240
241	<p>This will back out the changes that the merge or update made to the
242	working checkout. There is also a <b>redo</b> command if you undo by
243	mistake. Undo and redo only work for changes that have
244	not yet been checked in using <b>commit</b> and there is only a single
245	level of undo/redo.</p>
246
247
248	<a name="serversetup"></a>
249	</blockquote><h2>Setting Up A Server</h2><blockquote>
250
251	<p>The easiest way to set up a server is:</p>
252

Fossil SCM

Keyboard Shortcuts