Fossil

Check-in [1335cf41]
Login

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

Overview
Comment:Fix typos in the whyusefossil.wiki document.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:1335cf4135f5c6ead1fec823be69bf2dd6e20a79
User & Date: drh 2016-09-21 13:44:13
Context
2016-09-21
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
03:03
Fix a couple more typos. check-in: 8ac01fa6 user: mistachkin tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/whyusefossil.wiki.

47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
..
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
      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
         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 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.
     </ul>
................................................................................
          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>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.
................................................................................
      repository.  A "pull" by itself does not modify any check-out.  The
      "pull" command only moves content between repositories.  However,
      the "update" command will (often) automatically do a "pull" before
      attempting to update the local check-out.
  <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.







|

|







 







|



|







 







|







47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
..
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
      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.
     </ul>
................................................................................
          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 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.
................................................................................
      repository.  A "pull" by itself does not modify any check-out.  The
      "pull" command only moves content between repositories.  However,
      the "update" command will (often) automatically do a "pull" before
      attempting to update the local check-out.
  <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 be
      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.