Fossil

Check-in [f2ce2e41]
Login

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

Overview
Comment:More typo fixes in whyusefossil.wiki.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:f2ce2e41d573169bd58f872dd6de568c73e43947
User & Date: drh 2016-09-21 14:13:13
Context
2016-09-21
16:59
Re-fix several typos. check-in: 6e1072c5 user: mistachkin tags: trunk
16:06
Merge in latest from trunk check-in: 85a0ada6 user: nick.lloyd tags: nick.lloyd-git-interop
14:13
More typo fixes in whyusefossil.wiki. check-in: f2ce2e41 user: drh tags: trunk
13:44
Fix typos in the whyusefossil.wiki document. check-in: 1335cf41 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/whyusefossil.wiki.

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
..
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
     <li>Regulatory compliance
     </ol>
   <li><p><b>Automatic replication and backup</b>
     <ol type='i'>
     <li>Everyone always has the latest code
     <li>Failed disk-drives cause no loss of work
     <li>Avoid wasting time doing manual file copying
     <li>Avoid human errors during manual backups
     </ol>
  </ol>
<li><p><b>Definitions</b></p>
  <ul>
  <li><p><b>Project</b> &rarr;
       a collection of computer files that serve some common
      purpose.  Often the project is a software application and the
      individual files are source code together with makefiles, scripts, and
      "README.txt" files.  Other examples of projects include books or
      manuals in which each chapter or section is held in a separate file.
     <ul>
     <li><p>Projects change and evolve.  The whole purpose of version
         control is to track and manage that evolution.
     <li><p>Most projects consist of multiple files, but it is possible
         to have a project consisting of just a single file.
     <li><p>Fossil (and most other version control systems) requires that
         all the files for a project must be collected into a single
         directory hierarchy - a single folder possibly with layers
         of subfolders.  Fossil is not a good choice for managing a
         project that has files scattered hither and yon all over
         the disk.  In other words, Fossil only works for projects
         where the files are laid out such that they can be archived
         into a ZIP file or tarball.
................................................................................
          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 recover 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 repositories to 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>Check-out</b> &rarr;
      a set of files that have been extracted from a
      repository and that represent a particular version or snapshot of
      the project.
      <ul>
      <li><p>Check-outs must be on the same computer as the repository from
          which they are extracted.  This is just like with a ZIP archive:
          one must have the ZIP archive file on the local machine before
................................................................................
      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>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,







|













|

|







 







|




|







 







|







 







|







32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
..
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
...
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
...
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
     <li>Regulatory compliance
     </ol>
   <li><p><b>Automatic replication and backup</b>
     <ol type='i'>
     <li>Everyone always has the latest code
     <li>Failed disk-drives cause no loss of work
     <li>Avoid wasting time doing manual file copying
     <li>Avoid human errors during manual backups.
     </ol>
  </ol>
<li><p><b>Definitions</b></p>
  <ul>
  <li><p><b>Project</b> &rarr;
       a collection of computer files that serve some common
      purpose.  Often the project is a software application and the
      individual files are source code together with makefiles, scripts, and
      "README.txt" files.  Other examples of projects include books or
      manuals in which each chapter or section is held in a separate file.
     <ul>
     <li><p>Projects change and evolve.  The whole purpose of version
         control is to track and manage that evolution.
     <li><p>Most projects contain many files, but it is possible
         to have a project consisting of just a single file.
     <li><p>Fossil requires that
         all the files for a project must be collected into a single
         directory hierarchy - a single folder possibly with layers
         of subfolders.  Fossil is not a good choice for managing a
         project that has files scattered hither and yon all over
         the disk.  In other words, Fossil only works for projects
         where the files are laid out such that they can be archived
         into a ZIP file or tarball.
................................................................................
          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 recover 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 repositories to 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.
      <ul>
      <li><p>Check-outs must be on the same computer as the repository from
          which they are extracted.  This is just like with a ZIP archive:
          one must have the ZIP archive file on the local machine before
................................................................................
      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>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,