Why You Should Use Fossil

Why You Should Use Fossil

(Or if not Fossil, at least some kind of modern version control such as Git, Mercurial, or Subversion.)

I. Benefits of Version Control
  1. Immutable file and version identification

    1. Simplified and unambiguous communication between developers
    2. Detect accidental or surreptitious changes
    3. Locate the origin of discovered files

  2. Parallel development

    1. Multiple developers on the same project
    2. Single developer with multiple subprojects
    3. Experimental features do not contaminate the main line
    4. Development/Testing/Release branches
    5. Incorporate external changes into the baseline

  3. Historical record

    1. Exactly reconstruct historical builds
    2. Locate when and by whom faults were injected
    3. Find when and why content was added or removed
    4. Team members see the big picture
    5. Research the history of project features or subsystems
    6. Copyright and patent documentation
    7. Regulatory compliance

  4. Automatic replication and backup

    1. Everyone always has the latest code
    2. Failed disk-drives cause no loss of work
    3. Avoid wasting time doing manual file copying
    4. Avoid human errors during manual backups

II. Definitions
Moved to a separate document.
III. Basic Fossil commands
IV. The history of a project is a Directed Acyclic Graph (DAG)
V. Why version control is important (reprise)
  1. Every check-in and every individual file has a unique name - its SHA1 or SHA3-256 hash. Team members can unambiguously identify any specific version of the overall project or any specific version of an individual file.

  2. Any historical version of the whole project or of any individual file can be easily recreated at any time and by any team member.

  3. Accidental changes to files can be detected by recomputing their cryptographic hash.

  4. Files of unknown origin can be identified using their hash.

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

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

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

  8. Older changes can be easily backed out of recent revisions, for example if bugs are found long after the code was committed.

  9. Enhancements in a branch can be easily copied into other branches, or into the trunk.

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

  11. New team members can be brought up-to-date with all of the historical code, quickly and easily.

  12. New developers, interns, or inexperienced staff members who still do not understand all the details of the project or who are otherwise prone to making mistakes can be assigned significant subprojects to be carried out in branches without risking main line stability.

  13. Code is automatically synchronized across all machines. No human effort is wasted copying files from machine to machine. The risk of human errors during file transfer and backup is eliminated.

  14. A hardware failure results in minimal lost work because all previously committed changes will have been automatically replicated on other machines.

  15. The complete work history of the project is conveniently archived in a single file, simplifying long-term record keeping.

  16. A precise historical record is maintained which can be used to support copyright and patent claims or regulatory compliance.