Fossil

Check-in [680f3c1d]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix a couple typos.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 680f3c1d08394418cb80cd29fa78cb74f29ce3a0
User & Date: mistachkin 2016-09-21 03:00:24
Context
2016-09-21
03:03
Fix a couple more typos. check-in: 8ac01fa6 user: mistachkin tags: trunk
03:00
Fix a couple typos. check-in: 680f3c1d user: mistachkin tags: trunk
00:57
Add the "Why Use Fossil" document. check-in: d8b18eb9 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/whyusefossil.wiki.

62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
..
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
...
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
...
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
         into a ZIP file or tarball.
     </ul>
  <li><p><b>Repository</b>
      (also called "repo") &rarr; a single file that contains
      all historical versions of all files in a project.  A repo is similar
      to a ZIP archive in that it is a single file that stores compressed
      versions of many other files.  Files can be extracted from the
      repo and new files can be added to the repo, just as with a ZIP 
      archive.  But a repo has other capabilities above and beyond
      what a ZIP archive can do.
      <ul>
      <li><p>Fossil does not care what you name your repository files,
          though names ending with ".fossil" are recommended.
      <li><p>A single project typically has multiple, redundant repositories on
      separate machines.
................................................................................
          about that project.  So if any one repo is lost due to a disk
          crash, all content is preserved in the surviving repos.
      <li><p>The usual arrangement is one repository per user.  And since
          most users these days have their own computer, that means one
          repository per computer.  But this is not a requirement.  It is
          ok to have multiple copies of the same repository on the same
          computer.
      <li><p>Fossil works fine with just a single copy of the repository. 
          But in that case there is no redundancy.  If that one repository
          file is lost due to a hardware malfunction, then there is no way
          to recovery the project.
      <li><p>Best practice is to keep all repositories for a user in a single
          folder.  Folders such as "~/Fossils" or "%USERPROFILE%\Fossils"
          are recommanded.  Fossil itself does not care where the repositories
          are stored.  Nor does Fossil require that repositories all be
          kept in the same folder.  But it is easier to organize your work
          if all repositories are kept in the same place.
      </ul>
  <li><p><b>Checkout</b> &rarr;
      a set of files that have been extracted from a
      repository and that represent a particular version or snapshot of
................................................................................
      the project the check-out represents.  This is the ".fslckout" file
      on unix systems or the "_FOSSIL_" file on Windows.
      </ul>
  <li><p><b>Check-in</b> &rarr;
      another name for a particular version of the project.
      A check-in is a collection of files inside of a repository that
      represent a snapshot of the project for an instant in time.
      Check-ins exist only inside of the repository.  This constrasts with
      a check-out which is a collection of files outside of the repository.
      <ul>
      <li><p>Every check-out knows the check-in from which it was derived.
          But check-outs might have been edited and so might not exactly
          match their associated check-in.
      <li><p>Check-ins are immutable.  They can never be changed.  But
          check-outs are collections of ordinary files on disk.  The
................................................................................
  <li><p><b>sync</b> &rarr;
      Do both a "push" and a "pull" at the same time.
  <li><p><b>add</b> &rarr;
      Add a new file to the local check-out.  The file must already
      on disk.  This command tells Fossil to start tracking and managing
      the file.  This command affects only the local check-out and does
      not modify any repository.  The new file is inserted into the
      repository at the next "commit" command. 
  <li><p><b>rm/mv</b> &rarr;
      Short for 'remove' and 'move', these commands are like "add"
      in that they specify pending changes to the structure of the check-out.
      As with "add", no changes are made to the repository until the next
      "commit".
  </ul>
<li><p><b>The history of a project is a Directed Acyclic Graph (DAG)</b>
................................................................................
      <li><p>Each check-in is a node in the graph
      <li><p>If check-in X is derived from check-in Y then there is
          an arc in the graph from node X to node Y.
      <li><p>The older check-in (X) is call the "parent" and the newer
          check-in (Y) is the "child".  The child is derived from
          the parent.
      </ul>
  <li><p>Two users (or the same user working in different check-outs) 
      might commit different changes against the same check-in.  This 
      results in one parent node having two or more children.
  <li><p>Command: <b>merge</b> &rarr;
      combines the work of multiple check-ins into
      a single check-out.  That check-out can then be committed to create
      a new that has two (or more) parents.
      <ul>
      <li><p>Most check-ins have just one parent, and either zero or
................................................................................
  <li><p>Files of unknown origin can be identified using their SHA1 hash.
  <li><p>Developers are able to work in parallel, review each others work,
      and easily merge their changes together.  External revisions to
      the baseline can be easily incorporated into the latest changes.
  <li><p>Developers can follow experimental lines of development,  then
      revert back to an earlier stable version if the experiment does
      not work out.  Creativity is enhanced by allowing crazy ideas to
      be investigated without destablizing the project.
  <li><p>Developers can work on several independent subprojects, flipping
      back and forth from one subproject to another at will, and merge
      patches together or back into the main line of development as they
      mature.
  <li><p>Older changes can be easily backed out of recent revisions, for
      example if bugs are found long after the code was committed.
  <li><p>Enhancements in a branch can be easily copied into other branches,
      or into the trunk.
  <li><p>The complete history of all changes is plainly visible to 
      all team members.  Project leaders can easily keep track of what
      all team members are doing.  Check-in comments help everyone to
      understand and/or remember the reason for each change.
  <li><p>New team members can be brought up-to-date with all of the historical
      code, quickly and easily.
  <li><p>New developers, interns, or inexperienced staff members who still
      do not understand all the details of the project or who are otherwise







|







 







|





|







 







|







 







|







 







|
|







 







|








|







62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
..
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
...
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
...
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
         into a ZIP file or tarball.
     </ul>
  <li><p><b>Repository</b>
      (also called "repo") &rarr; a single file that contains
      all historical versions of all files in a project.  A repo is similar
      to a ZIP archive in that it is a single file that stores compressed
      versions of many other files.  Files can be extracted from the
      repo and new files can be added to the repo, just as with a ZIP
      archive.  But a repo has other capabilities above and beyond
      what a ZIP archive can do.
      <ul>
      <li><p>Fossil does not care what you name your repository files,
          though names ending with ".fossil" are recommended.
      <li><p>A single project typically has multiple, redundant repositories on
      separate machines.
................................................................................
          about that project.  So if any one repo is lost due to a disk
          crash, all content is preserved in the surviving repos.
      <li><p>The usual arrangement is one repository per user.  And since
          most users these days have their own computer, that means one
          repository per computer.  But this is not a requirement.  It is
          ok to have multiple copies of the same repository on the same
          computer.
      <li><p>Fossil works fine with just a single copy of the repository.
          But in that case there is no redundancy.  If that one repository
          file is lost due to a hardware malfunction, then there is no way
          to recovery the project.
      <li><p>Best practice is to keep all repositories for a user in a single
          folder.  Folders such as "~/Fossils" or "%USERPROFILE%\Fossils"
          are recommended.  Fossil itself does not care where the repositories
          are stored.  Nor does Fossil require that repositories all be
          kept in the same folder.  But it is easier to organize your work
          if all repositories are kept in the same place.
      </ul>
  <li><p><b>Checkout</b> &rarr;
      a set of files that have been extracted from a
      repository and that represent a particular version or snapshot of
................................................................................
      the project the check-out represents.  This is the ".fslckout" file
      on unix systems or the "_FOSSIL_" file on Windows.
      </ul>
  <li><p><b>Check-in</b> &rarr;
      another name for a particular version of the project.
      A check-in is a collection of files inside of a repository that
      represent a snapshot of the project for an instant in time.
      Check-ins exist only inside of the repository.  This contrasts with
      a check-out which is a collection of files outside of the repository.
      <ul>
      <li><p>Every check-out knows the check-in from which it was derived.
          But check-outs might have been edited and so might not exactly
          match their associated check-in.
      <li><p>Check-ins are immutable.  They can never be changed.  But
          check-outs are collections of ordinary files on disk.  The
................................................................................
  <li><p><b>sync</b> &rarr;
      Do both a "push" and a "pull" at the same time.
  <li><p><b>add</b> &rarr;
      Add a new file to the local check-out.  The file must already
      on disk.  This command tells Fossil to start tracking and managing
      the file.  This command affects only the local check-out and does
      not modify any repository.  The new file is inserted into the
      repository at the next "commit" command.
  <li><p><b>rm/mv</b> &rarr;
      Short for 'remove' and 'move', these commands are like "add"
      in that they specify pending changes to the structure of the check-out.
      As with "add", no changes are made to the repository until the next
      "commit".
  </ul>
<li><p><b>The history of a project is a Directed Acyclic Graph (DAG)</b>
................................................................................
      <li><p>Each check-in is a node in the graph
      <li><p>If check-in X is derived from check-in Y then there is
          an arc in the graph from node X to node Y.
      <li><p>The older check-in (X) is call the "parent" and the newer
          check-in (Y) is the "child".  The child is derived from
          the parent.
      </ul>
  <li><p>Two users (or the same user working in different check-outs)
      might commit different changes against the same check-in.  This
      results in one parent node having two or more children.
  <li><p>Command: <b>merge</b> &rarr;
      combines the work of multiple check-ins into
      a single check-out.  That check-out can then be committed to create
      a new that has two (or more) parents.
      <ul>
      <li><p>Most check-ins have just one parent, and either zero or
................................................................................
  <li><p>Files of unknown origin can be identified using their SHA1 hash.
  <li><p>Developers are able to work in parallel, review each others work,
      and easily merge their changes together.  External revisions to
      the baseline can be easily incorporated into the latest changes.
  <li><p>Developers can follow experimental lines of development,  then
      revert back to an earlier stable version if the experiment does
      not work out.  Creativity is enhanced by allowing crazy ideas to
      be investigated without destabilizing the project.
  <li><p>Developers can work on several independent subprojects, flipping
      back and forth from one subproject to another at will, and merge
      patches together or back into the main line of development as they
      mature.
  <li><p>Older changes can be easily backed out of recent revisions, for
      example if bugs are found long after the code was committed.
  <li><p>Enhancements in a branch can be easily copied into other branches,
      or into the trunk.
  <li><p>The complete history of all changes is plainly visible to
      all team members.  Project leaders can easily keep track of what
      all team members are doing.  Check-in comments help everyone to
      understand and/or remember the reason for each change.
  <li><p>New team members can be brought up-to-date with all of the historical
      code, quickly and easily.
  <li><p>New developers, interns, or inexperienced staff members who still
      do not understand all the details of the project or who are otherwise