|
1
|
<title>Why You Should Use Fossil</title> |
|
2
|
|
|
3
|
<h4>(Or if not Fossil, at least some kind of modern |
|
4
|
version control such as Git, Mercurial, or Subversion.)</h4> |
|
5
|
|
|
6
|
<h5>I. Benefits of Version Control</h5> |
|
7
|
|
|
8
|
<ol type='A'> |
|
9
|
<li><p><b>Immutable file and version identification</b> |
|
10
|
<ol type='i'> |
|
11
|
<li>Simplified and unambiguous communication between developers |
|
12
|
<li>Detect accidental or surreptitious changes |
|
13
|
<li>Locate the origin of discovered files |
|
14
|
</ol> |
|
15
|
<li><p><b>Parallel development</b> |
|
16
|
<ol type='i'> |
|
17
|
<li>Multiple developers on the same project |
|
18
|
<li>Single developer with multiple subprojects |
|
19
|
<li>Experimental features do not contaminate the main line |
|
20
|
<li>Development/Testing/Release branches |
|
21
|
<li>Incorporate external changes into the baseline |
|
22
|
</ol> |
|
23
|
<li><p><b>Historical record</b> |
|
24
|
<ol type='i'> |
|
25
|
<li>Exactly reconstruct historical builds |
|
26
|
<li>Locate when and by whom faults were injected |
|
27
|
<li>Find when and why content was added or removed |
|
28
|
<li>Team members see the big picture |
|
29
|
<li>Research the history of project features or subsystems |
|
30
|
<li>Copyright and patent documentation |
|
31
|
<li>Regulatory compliance |
|
32
|
</ol> |
|
33
|
<li><p><b>Automatic replication and backup</b> |
|
34
|
<ol type='i'> |
|
35
|
<li>Everyone always has the latest code |
|
36
|
<li>Failed disk-drives cause no loss of work |
|
37
|
<li>Avoid wasting time doing manual file copying |
|
38
|
<li>Avoid human errors during manual backups |
|
39
|
</ol> |
|
40
|
</ol> |
|
41
|
|
|
42
|
<h5 id="definitions">II. Definitions</h5> |
|
43
|
|
|
44
|
<div class="indent">Moved to [./glossary.md | a separate document].</div> |
|
45
|
|
|
46
|
<h5>III. Basic Fossil commands</h5> |
|
47
|
|
|
48
|
<ul> |
|
49
|
<li><p><b>clone</b> → |
|
50
|
Make a copy of a repository. The original repository |
|
51
|
is usually (but not always) on a remote machine and the copy is on |
|
52
|
the local machine. The copy remembers the network location from |
|
53
|
which it was copied and (by default) tries to keep itself synchronized |
|
54
|
with the original. |
|
55
|
<li><p><b>open</b> → |
|
56
|
Create a new check-out from a repository on the local machine. |
|
57
|
<li><p><b>update</b> → |
|
58
|
Modify an existing check-out so that it is derived from a |
|
59
|
different version of the same project. |
|
60
|
<li><p><b>commit</b> → |
|
61
|
Create a new version (a new check-in) of the project that |
|
62
|
is a snapshot of the current check-out. |
|
63
|
<li><p><b>revert</b> → |
|
64
|
Undo all local edits on a check-out. Make the check-out |
|
65
|
be an exact copy of its associated check-in. |
|
66
|
<li><p><b>push</b> → |
|
67
|
Copy content found in a local repository over to a remote |
|
68
|
repository. (Fossil usually does this automatically in response to |
|
69
|
a "commit" and so this command is seldom used, but it is important |
|
70
|
to understand it.) |
|
71
|
<li><p><b>pull</b> → |
|
72
|
Copy new content found in a remote repository into a local |
|
73
|
repository. A "pull" by itself does not modify any check-out. The |
|
74
|
"pull" command only moves content between repositories. However, |
|
75
|
the "update" command will (often) automatically do a "pull" before |
|
76
|
attempting to update the local check-out. |
|
77
|
<li><p><b>sync</b> → |
|
78
|
Do both a "push" and a "pull" at the same time. |
|
79
|
<li><p><b>add</b> → |
|
80
|
Add a new file to the local check-out. The file must already be |
|
81
|
on disk. This command tells Fossil to start tracking and managing |
|
82
|
the file. This command affects only the local check-out and does |
|
83
|
not modify any repository. The new file is inserted into the |
|
84
|
repository at the next "commit" command. |
|
85
|
<li><p><b>rm/mv</b> → |
|
86
|
Short for 'remove' and 'move', these commands are like "add" |
|
87
|
in that they specify pending changes to the structure of the check-out. |
|
88
|
As with "add", no changes are made to the repository until the next |
|
89
|
"commit". |
|
90
|
</ul> |
|
91
|
|
|
92
|
<h5>IV. The history of a project is a Directed Acyclic Graph (DAG)</h5> |
|
93
|
|
|
94
|
<ul> |
|
95
|
<li><p>Fossil (and other distributed VCSes like Git and Mercurial, but |
|
96
|
not Subversion) represent |
|
97
|
the history of a project as a directed acyclic graph (DAG). |
|
98
|
<ul> |
|
99
|
<li><p>Each check-in is a node in the graph |
|
100
|
<li><p>If check-in Y is derived from check-in X then there is |
|
101
|
an arc in the graph from node X to node Y. |
|
102
|
<li><p>The older check-in (X) is call the "parent" and the newer |
|
103
|
check-in (Y) is the "child". The child is derived from |
|
104
|
the parent. |
|
105
|
</ul> |
|
106
|
<li><p>Two users (or the same user working in different check-outs) |
|
107
|
might commit different changes against the same check-in. This |
|
108
|
results in one parent node having two or more children. |
|
109
|
<li><p>Command: <b>merge</b> → |
|
110
|
combines the work of multiple check-ins into |
|
111
|
a single check-out. That check-out can then be committed to create |
|
112
|
a new check-in that has two (or more) parents. |
|
113
|
<ul> |
|
114
|
<li><p>Most check-ins have just one parent, and either zero or |
|
115
|
one child. |
|
116
|
<li><p>When a check-in has two or more parents, one of those parents |
|
117
|
is the "primary parent". All the other parent nodes are "secondary" |
|
118
|
or "merge" parents. |
|
119
|
Conceptually, the primary parent shows the main line of |
|
120
|
development. Content from the merge parents is added |
|
121
|
into the main line. |
|
122
|
<li><p>The "direct children" of a check-in X are all children that |
|
123
|
have X as their primary parent. |
|
124
|
<li><p>A check-in node with no direct children is sometimes called |
|
125
|
a "leaf". |
|
126
|
<li><p>The "merge" command changes only the check-out. |
|
127
|
The "commit" command must be run subsequently to make the merge |
|
128
|
a permanent part of project. |
|
129
|
</ul> |
|
130
|
<li><p>Definition: <b>branch</b> → |
|
131
|
a sequence of check-ins that are all linked |
|
132
|
together in the DAG through the primary parent. |
|
133
|
<ul> |
|
134
|
<li><p>Branches are often given names which propagate to direct children. |
|
135
|
The tradition in Fossil is to call the main branch "trunk". In |
|
136
|
Git, it's called "master" by default, though some call it |
|
137
|
something else, like "main". |
|
138
|
<li><p>It is possible to have multiple branches with the same name. |
|
139
|
Fossil has no problem with this, but it can be confusing to |
|
140
|
humans, so best practice is to give each branch a unique name. |
|
141
|
<li><p>The name of a branch can be changed by adding special tags |
|
142
|
to the first check-in of a branch. The name assigned by this |
|
143
|
special tag automatically propagates to all direct children. |
|
144
|
</ul> |
|
145
|
</ul> |
|
146
|
|
|
147
|
<h5>V. Why version control is important (reprise)</h5> |
|
148
|
|
|
149
|
<ol> |
|
150
|
<li><p>Every check-in and every individual file has a unique name - its |
|
151
|
SHA1 or SHA3-256 hash. Team members can unambiguously identify |
|
152
|
any specific |
|
153
|
version of the overall project or any specific version of an |
|
154
|
individual file. |
|
155
|
<li><p>Any historical version of the whole project or of any individual |
|
156
|
file can be easily recreated at any time and by any team member. |
|
157
|
<li><p>Accidental changes to files can be detected by recomputing their |
|
158
|
cryptographic hash. |
|
159
|
<li><p>Files of unknown origin can be identified using their hash. |
|
160
|
<li><p>Developers are able to work in parallel, review each others work, |
|
161
|
and easily merge their changes together. External revisions to |
|
162
|
the baseline can be easily incorporated into the latest changes. |
|
163
|
<li><p>Developers can follow experimental lines of development, then |
|
164
|
revert back to an earlier stable version if the experiment does |
|
165
|
not work out. Creativity is enhanced by allowing crazy ideas to |
|
166
|
be investigated without destabilizing the project. |
|
167
|
<li><p>Developers can work on several independent subprojects, flipping |
|
168
|
back and forth from one subproject to another at will, and merge |
|
169
|
patches together or back into the main line of development as they |
|
170
|
mature. |
|
171
|
<li><p>Older changes can be easily backed out of recent revisions, for |
|
172
|
example if bugs are found long after the code was committed. |
|
173
|
<li><p>Enhancements in a branch can be easily copied into other branches, |
|
174
|
or into the trunk. |
|
175
|
<li><p>The complete history of all changes is plainly visible to |
|
176
|
all team members. Project leaders can easily keep track of what |
|
177
|
all team members are doing. Check-in comments help everyone to |
|
178
|
understand and/or remember the reason for each change. |
|
179
|
<li><p>New team members can be brought up-to-date with all of the historical |
|
180
|
code, quickly and easily. |
|
181
|
<li><p>New developers, interns, or inexperienced staff members who still |
|
182
|
do not understand all the details of the project or who are otherwise |
|
183
|
prone to making mistakes can be assigned significant subprojects to |
|
184
|
be carried out in branches without risking main line stability. |
|
185
|
<li><p>Code is automatically synchronized across all machines. No human |
|
186
|
effort is wasted copying files from machine to machine. The risk |
|
187
|
of human errors during file transfer and backup is eliminated. |
|
188
|
<li><p>A hardware failure results in minimal lost work because |
|
189
|
all previously committed changes will have been automatically |
|
190
|
replicated on other machines. |
|
191
|
<li><p>The complete work history of the project is conveniently archived |
|
192
|
in a single file, simplifying long-term record keeping. |
|
193
|
<li><p>A precise historical record is maintained which can be used to |
|
194
|
support copyright and patent claims or regulatory compliance. |
|
195
|
</ol> |
|
196
|
</ol> |
|
197
|
|