From 4f49b16079b27d7ce633619e4cddfdf2bffbc952 Mon Sep 17 00:00:00 2001 From: cashmere Date: Fri, 4 Sep 2026 09:05:24 +0200 Subject: initial commit --- www/whyusefossil.wiki | 196 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 196 insertions(+) create mode 100644 www/whyusefossil.wiki (limited to 'www/whyusefossil.wiki') diff --git a/www/whyusefossil.wiki b/www/whyusefossil.wiki new file mode 100644 index 0000000..7cbc8aa --- /dev/null +++ b/www/whyusefossil.wiki @@ -0,0 +1,196 @@ +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 [./glossary.md | 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. +

+ -- cgit v1.3.1