<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
................................................................................
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,

<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
................................................................................
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,

This page was generated in about
0.006s by
Fossil 2.8 [246f249e5a] 2019-01-21 20:07:41