Fossil SCM
Change the markup in the index.wiki page from HTML to wiki. Extend the wikitheory.wiki page. Other documentation tweaks.
Commit
7083eb1a1c7a32206a0960e354899d2c2058554c
Parent
0c6ea0d93f03647…
4 files changed
+1
-1
+75
-86
+26
-3
+46
-9
+1
-1
| --- www/bugtheory.wiki | ||
| +++ www/bugtheory.wiki | ||
| @@ -7,11 +7,11 @@ | ||
| 7 | 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | 9 | rejected in fossil for three reasons: |
| 10 | 10 | |
| 11 | 11 | 1. Check-ins (a.k.a. "baselines") in fossil are immutable. So if |
| 12 | - tickets were part of the check-in, then there would no way to add | |
| 12 | + tickets were part of the check-in, then there would be no way to add | |
| 13 | 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | 14 | |
| 15 | 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 | 17 | cluttering the source tree. |
| 18 | 18 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -7,11 +7,11 @@ | |
| 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | rejected in fossil for three reasons: |
| 10 | |
| 11 | 1. Check-ins (a.k.a. "baselines") in fossil are immutable. So if |
| 12 | tickets were part of the check-in, then there would no way to add |
| 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | |
| 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 | cluttering the source tree. |
| 18 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -7,11 +7,11 @@ | |
| 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | rejected in fossil for three reasons: |
| 10 | |
| 11 | 1. Check-ins (a.k.a. "baselines") in fossil are immutable. So if |
| 12 | tickets were part of the check-in, then there would be no way to add |
| 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | |
| 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 | cluttering the source tree. |
| 18 |
+75
-86
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -1,103 +1,92 @@ | ||
| 1 | 1 | <h1>Fossil: Distributed Revision Control, Wiki, and Bug-Tracking</h1> |
| 2 | 2 | |
| 3 | -<p> | |
| 4 | 3 | Fossil is a |
| 5 | -<a href="http://en.wikipedia.org/wiki/Revision_control"> | |
| 6 | -distributed software revision control system</a> that includes an integrated | |
| 7 | -<a href="wikitheory.wiki">wiki</a> and an integrated | |
| 8 | -<a href="bugtheory.wiki">bug-tracking system</a> all in a single, | |
| 4 | +[http://en.wikipedia.org/wiki/Revision_control | distributed software version control system] | |
| 5 | +that includes an integrated | |
| 6 | +[./wikitheory.wiki | distributed wiki] and an integrated | |
| 7 | +[./bugtheory.wiki | distributed bug-tracking system] all in a single, | |
| 9 | 8 | easy-to-use, stand-alone executable. |
| 10 | -Fossil is | |
| 11 | -<a href="http://www.fossil-scm.org/">self-hosting</a> | |
| 9 | +Fossil is [http://www.fossil-scm.org/ | self-hosting] | |
| 12 | 10 | since 2007-07-21 on |
| 13 | -<a href="http://www.hwaci.com/cgi-bin/fossil">two separate servers</a>. | |
| 14 | -You can download the <a href="../../../timeline">latest sources</a> and | |
| 15 | -<a href="build.wiki">compile it yourself</a>. | |
| 11 | +[http://www.hwaci.com/cgi-bin/fossil | two separate servers]. | |
| 12 | +You can download the [/timeline?y=ci | latest sources] and | |
| 13 | +[./build.wiki | compile it yourself]. | |
| 16 | 14 | Or you can grab |
| 17 | -<a href="http://www.fossil-scm.org/download.html">pre-compiled binaries</a>. | |
| 18 | -</p> | |
| 15 | +[http://www.fossil-scm.org/download.html | pre-compiled binaries]. | |
| 16 | + | |
| 19 | 17 | |
| 20 | -<p>Feature Summary:</p> | |
| 18 | +Feature Summary: | |
| 21 | 19 | |
| 22 | -<ul> | |
| 23 | -<li>Flexible workflow:<ul> | |
| 20 | + * Flexible workflow:<ul> | |
| 24 | 21 | <li>Disconnected, distributed development like |
| 25 | 22 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 26 | 23 | <a href="http://www.monotone.ca/">monotone</a>, |
| 27 | 24 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, |
| 28 | 25 | and <a href="http://www.bitkeeper.com/">bitkeeper</a> |
| 29 | 26 | <li>Or, client/server operation like |
| 30 | 27 | <a href="http://www.nongnu.org/cvs/">CVS</a> and |
| 31 | 28 | <a href="http://subversion.tigris.org/">subversion</a>, |
| 32 | 29 | <li>Or, operations on local repositories, |
| 33 | - <li>Or, all of the above at the same time</ul></li> | |
| 34 | -<li>Integrated, distributed <a href="bugtheory.wiki">bug tracking</a> and | |
| 35 | -<a href="wikitheory.wiki">wiki</a>.</li> | |
| 36 | -<li>Built-in web interface that supports deep archaeological digs through | |
| 37 | -the project history.</li> | |
| 38 | -<li>All network communication via | |
| 39 | -<a href="http://en.wikipedia.org/wiki/HTTP">HTTP</a> with | |
| 40 | -<a href="quickstart.wiki#proxy">proxy support</a> | |
| 41 | -so that everything works from behind restrictive firewalls.</li> | |
| 42 | -<li>Everything (client, server, and utilities) is included in a | |
| 43 | -single self-contained executable - trivial to install</li> | |
| 44 | -<li>Server runs as <a href="quickstart.wiki#cgiserver">CGI</a>, using | |
| 45 | -<a href="quickstart.wiki#inetdserver">inetd/xinetd</a> | |
| 46 | -or using its own | |
| 47 | -<a href="quickstart.wiki#serversetup">built-in, stand alone web server</a>.</li> | |
| 48 | -<li>An entire project contained in single disk file | |
| 49 | -(an <a href="http://www.sqlite.org/">SQLite</a> database.)</li> | |
| 50 | -<li>Uses an <a href="fileformat.wiki">enduring file format</a> that is | |
| 51 | -designed to be readable, searchable, and extensible by people not yet born.</li> | |
| 52 | -<li>Automatic <a href="selfcheck.wiki">self-check</a> | |
| 53 | -on repository changes makes it exceedingly | |
| 54 | -unlikely that data will ever be lost because of a software bug.</li> | |
| 55 | -<li>Ridiculously easy to | |
| 56 | -<a href="build.wiki">install</a> and | |
| 57 | -<a href="quickstart.wiki">operate</a>.</li> | |
| 58 | -</ul> | |
| 59 | - | |
| 60 | -<p>User Links:</p> | |
| 61 | - | |
| 62 | -<ul> | |
| 63 | -<li>The <a href="concepts.wiki">concepts</b> behind fossil</li> | |
| 64 | -<li><a href="build.wiki">Building And Installing</a></li> | |
| 65 | -<li><a href="quickstart.wiki">Quick Start</a> guide to using fossil | |
| 66 | -<li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a> | |
| 67 | - that is versioned along with project source code.</li> | |
| 68 | -<li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism | |
| 69 | -helps insure project integrity.</li> | |
| 70 | -<li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li> | |
| 71 | -<li>There is a | |
| 72 | - <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> | |
| 73 | - mailing list</a> available for discussing fossil issues.</li> | |
| 74 | -<li><a href="qandc.wiki">Questions & Criticisms</a> directed at fossil.</li> | |
| 75 | -<li>Some (unfinished but expanding) extended | |
| 76 | - <a href="reference.wiki">reference documentation</a> for the fossil command line. | |
| 77 | -</ul> | |
| 78 | - | |
| 79 | -<p>Developer Links: </p> | |
| 80 | - | |
| 81 | -<ul> | |
| 82 | -<li><a href="pop.wiki">Principles Of Operation</a></li> | |
| 83 | -<li>The <a href="fileformat.wiki">file format</a> used by every content | |
| 84 | -file stored in the repository.</li> | |
| 85 | -<li>The <a href="delta_format.wiki">format of deltas</a> used to | |
| 86 | -efficiently store changes between file revisions.</li> | |
| 87 | -<li>The <a href="delta_encoder_algorithm.wiki">encoder algorithm</a> used to | |
| 88 | -efficiently generate deltas.</li> | |
| 89 | -<li>The <a href="sync.wiki">synchronization protocol</a>.</li> | |
| 90 | -</ul> | |
| 91 | - | |
| 92 | -<p>Competing Projects:</p> | |
| 93 | - | |
| 94 | -<ul> | |
| 95 | -<li><a href="http://www.ditrack.org/">DITrace</a> | |
| 96 | - - A Distributed Issue Tracker</li> | |
| 97 | -<li><a href="http://www.distract.wellquite.org/">DisTract</a> | |
| 98 | - - Another distributed issue tracker based on | |
| 99 | - <a href="http://www.monotone.ca/">monotone</a>.</li> | |
| 100 | -<li><a href="http://www.monotone.ca/">Monotone</a> - distributed | |
| 101 | - SCM in a single-file executable with a single-file SQLite | |
| 102 | - database repository.</li> | |
| 103 | -</ul> | |
| 30 | + <li>Or, all of the above at the same time</ul> | |
| 31 | + * Integrated, [./bugtheory.wiki | distributed bug tracking] and | |
| 32 | + [./wikitheory.wiki | distributed wiki]. | |
| 33 | + * Built-in web interface that supports deep archaeological digs through | |
| 34 | + the project history. | |
| 35 | + * All network communication via | |
| 36 | + [http://en.wikipedia.org/wiki/HTTP | HTTP] with | |
| 37 | + [./quickstart.wiki#proxy | proxy support] | |
| 38 | + so that everything works from behind restrictive firewalls. | |
| 39 | + * Everything (client, server, and utilities) is included in a | |
| 40 | + single self-contained executable - trivial to install | |
| 41 | + * Server runs as [./quickstart.wiki#cgiserver | CGI], using | |
| 42 | + [./quickstart.wiki#inetdserver | inetd/xinetd] | |
| 43 | + or using its own | |
| 44 | + [./quickstart.wiki#serversetup | built-in, stand alone web server]. | |
| 45 | + * An entire project contained in single disk file | |
| 46 | + (an [http://www.sqlite.org/ | SQLite] database.) | |
| 47 | + * Uses an [./fileformat.wiki | enduring file format] that is | |
| 48 | + designed to be readable, searchable, and extensible by people | |
| 49 | + not yet born. | |
| 50 | + * Automatic [./selfcheck.wiki | self-check] | |
| 51 | + on repository changes makes it exceedingly | |
| 52 | + unlikely that data will ever be lost because of a software bug. | |
| 53 | + * Ridiculously easy to [./build.wiki | install] and | |
| 54 | + [./quickstart.wiki | operate]. | |
| 55 | + | |
| 56 | +User Links: | |
| 57 | + | |
| 58 | + * The [./concepts.wiki | concepts] behind fossil | |
| 59 | + * [./build.wiki | Building And Installing] | |
| 60 | + * [./quickstart.wiki | Quick Start] guide to using fossil | |
| 61 | + * Fossil supports [./embeddeddoc.wiki | embedded documentation] | |
| 62 | + that is versioned along with project source code. | |
| 63 | + * The [./selfcheck.wiki | automatic self-check] mechanism | |
| 64 | + helps insure project integrity. | |
| 65 | + * Fossil contains a [./wikitheory.wiki | built-in wiki]. | |
| 66 | + * There is a | |
| 67 | + [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] | |
| 68 | + available for discussing fossil issues. | |
| 69 | + * [./qandc.wiki | Questions & Criticisms] directed at fossil. | |
| 70 | + * Some (unfinished but expanding) extended | |
| 71 | + [./reference.wiki | reference documentation] for the fossil command line. | |
| 72 | + | |
| 73 | +Developer Links: | |
| 74 | + | |
| 75 | + * [./pop.wiki | Principles Of Operation] | |
| 76 | + * The [./fileformat.wiki | file format] used by every content | |
| 77 | + file stored in the repository. | |
| 78 | + * The [./delta_format.wiki | format of deltas] used to | |
| 79 | + efficiently store changes between file revisions. | |
| 80 | + * The [./delta_encoder_algorithm.wiki | encoder algorithm] used to | |
| 81 | + efficiently generate deltas. | |
| 82 | + * The [./sync.wiki | synchronization protocol]. | |
| 83 | + | |
| 84 | +Competing Projects: | |
| 85 | + | |
| 86 | + * [http://www.ditrack.org/ | DITrace] - A Distributed Issue Tracker | |
| 87 | + * [http://www.distract.wellquite.org/ | DisTract] | |
| 88 | + - Another distributed issue tracker based on | |
| 89 | + [http://www.monotone.ca/ | monotone]. | |
| 90 | + * [http://www.monotone.ca/ | Monotone] - distributed | |
| 91 | + SCM in a single-file executable with a single-file SQLite | |
| 92 | + database repository. | |
| 104 | 93 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -1,103 +1,92 @@ | |
| 1 | <h1>Fossil: Distributed Revision Control, Wiki, and Bug-Tracking</h1> |
| 2 | |
| 3 | <p> |
| 4 | Fossil is a |
| 5 | <a href="http://en.wikipedia.org/wiki/Revision_control"> |
| 6 | distributed software revision control system</a> that includes an integrated |
| 7 | <a href="wikitheory.wiki">wiki</a> and an integrated |
| 8 | <a href="bugtheory.wiki">bug-tracking system</a> all in a single, |
| 9 | easy-to-use, stand-alone executable. |
| 10 | Fossil is |
| 11 | <a href="http://www.fossil-scm.org/">self-hosting</a> |
| 12 | since 2007-07-21 on |
| 13 | <a href="http://www.hwaci.com/cgi-bin/fossil">two separate servers</a>. |
| 14 | You can download the <a href="../../../timeline">latest sources</a> and |
| 15 | <a href="build.wiki">compile it yourself</a>. |
| 16 | Or you can grab |
| 17 | <a href="http://www.fossil-scm.org/download.html">pre-compiled binaries</a>. |
| 18 | </p> |
| 19 | |
| 20 | <p>Feature Summary:</p> |
| 21 | |
| 22 | <ul> |
| 23 | <li>Flexible workflow:<ul> |
| 24 | <li>Disconnected, distributed development like |
| 25 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 26 | <a href="http://www.monotone.ca/">monotone</a>, |
| 27 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, |
| 28 | and <a href="http://www.bitkeeper.com/">bitkeeper</a> |
| 29 | <li>Or, client/server operation like |
| 30 | <a href="http://www.nongnu.org/cvs/">CVS</a> and |
| 31 | <a href="http://subversion.tigris.org/">subversion</a>, |
| 32 | <li>Or, operations on local repositories, |
| 33 | <li>Or, all of the above at the same time</ul></li> |
| 34 | <li>Integrated, distributed <a href="bugtheory.wiki">bug tracking</a> and |
| 35 | <a href="wikitheory.wiki">wiki</a>.</li> |
| 36 | <li>Built-in web interface that supports deep archaeological digs through |
| 37 | the project history.</li> |
| 38 | <li>All network communication via |
| 39 | <a href="http://en.wikipedia.org/wiki/HTTP">HTTP</a> with |
| 40 | <a href="quickstart.wiki#proxy">proxy support</a> |
| 41 | so that everything works from behind restrictive firewalls.</li> |
| 42 | <li>Everything (client, server, and utilities) is included in a |
| 43 | single self-contained executable - trivial to install</li> |
| 44 | <li>Server runs as <a href="quickstart.wiki#cgiserver">CGI</a>, using |
| 45 | <a href="quickstart.wiki#inetdserver">inetd/xinetd</a> |
| 46 | or using its own |
| 47 | <a href="quickstart.wiki#serversetup">built-in, stand alone web server</a>.</li> |
| 48 | <li>An entire project contained in single disk file |
| 49 | (an <a href="http://www.sqlite.org/">SQLite</a> database.)</li> |
| 50 | <li>Uses an <a href="fileformat.wiki">enduring file format</a> that is |
| 51 | designed to be readable, searchable, and extensible by people not yet born.</li> |
| 52 | <li>Automatic <a href="selfcheck.wiki">self-check</a> |
| 53 | on repository changes makes it exceedingly |
| 54 | unlikely that data will ever be lost because of a software bug.</li> |
| 55 | <li>Ridiculously easy to |
| 56 | <a href="build.wiki">install</a> and |
| 57 | <a href="quickstart.wiki">operate</a>.</li> |
| 58 | </ul> |
| 59 | |
| 60 | <p>User Links:</p> |
| 61 | |
| 62 | <ul> |
| 63 | <li>The <a href="concepts.wiki">concepts</b> behind fossil</li> |
| 64 | <li><a href="build.wiki">Building And Installing</a></li> |
| 65 | <li><a href="quickstart.wiki">Quick Start</a> guide to using fossil |
| 66 | <li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a> |
| 67 | that is versioned along with project source code.</li> |
| 68 | <li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism |
| 69 | helps insure project integrity.</li> |
| 70 | <li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li> |
| 71 | <li>There is a |
| 72 | <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 73 | mailing list</a> available for discussing fossil issues.</li> |
| 74 | <li><a href="qandc.wiki">Questions & Criticisms</a> directed at fossil.</li> |
| 75 | <li>Some (unfinished but expanding) extended |
| 76 | <a href="reference.wiki">reference documentation</a> for the fossil command line. |
| 77 | </ul> |
| 78 | |
| 79 | <p>Developer Links: </p> |
| 80 | |
| 81 | <ul> |
| 82 | <li><a href="pop.wiki">Principles Of Operation</a></li> |
| 83 | <li>The <a href="fileformat.wiki">file format</a> used by every content |
| 84 | file stored in the repository.</li> |
| 85 | <li>The <a href="delta_format.wiki">format of deltas</a> used to |
| 86 | efficiently store changes between file revisions.</li> |
| 87 | <li>The <a href="delta_encoder_algorithm.wiki">encoder algorithm</a> used to |
| 88 | efficiently generate deltas.</li> |
| 89 | <li>The <a href="sync.wiki">synchronization protocol</a>.</li> |
| 90 | </ul> |
| 91 | |
| 92 | <p>Competing Projects:</p> |
| 93 | |
| 94 | <ul> |
| 95 | <li><a href="http://www.ditrack.org/">DITrace</a> |
| 96 | - A Distributed Issue Tracker</li> |
| 97 | <li><a href="http://www.distract.wellquite.org/">DisTract</a> |
| 98 | - Another distributed issue tracker based on |
| 99 | <a href="http://www.monotone.ca/">monotone</a>.</li> |
| 100 | <li><a href="http://www.monotone.ca/">Monotone</a> - distributed |
| 101 | SCM in a single-file executable with a single-file SQLite |
| 102 | database repository.</li> |
| 103 | </ul> |
| 104 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -1,103 +1,92 @@ | |
| 1 | <h1>Fossil: Distributed Revision Control, Wiki, and Bug-Tracking</h1> |
| 2 | |
| 3 | Fossil is a |
| 4 | [http://en.wikipedia.org/wiki/Revision_control | distributed software version control system] |
| 5 | that includes an integrated |
| 6 | [./wikitheory.wiki | distributed wiki] and an integrated |
| 7 | [./bugtheory.wiki | distributed bug-tracking system] all in a single, |
| 8 | easy-to-use, stand-alone executable. |
| 9 | Fossil is [http://www.fossil-scm.org/ | self-hosting] |
| 10 | since 2007-07-21 on |
| 11 | [http://www.hwaci.com/cgi-bin/fossil | two separate servers]. |
| 12 | You can download the [/timeline?y=ci | latest sources] and |
| 13 | [./build.wiki | compile it yourself]. |
| 14 | Or you can grab |
| 15 | [http://www.fossil-scm.org/download.html | pre-compiled binaries]. |
| 16 | |
| 17 | |
| 18 | Feature Summary: |
| 19 | |
| 20 | * Flexible workflow:<ul> |
| 21 | <li>Disconnected, distributed development like |
| 22 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 23 | <a href="http://www.monotone.ca/">monotone</a>, |
| 24 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, |
| 25 | and <a href="http://www.bitkeeper.com/">bitkeeper</a> |
| 26 | <li>Or, client/server operation like |
| 27 | <a href="http://www.nongnu.org/cvs/">CVS</a> and |
| 28 | <a href="http://subversion.tigris.org/">subversion</a>, |
| 29 | <li>Or, operations on local repositories, |
| 30 | <li>Or, all of the above at the same time</ul> |
| 31 | * Integrated, [./bugtheory.wiki | distributed bug tracking] and |
| 32 | [./wikitheory.wiki | distributed wiki]. |
| 33 | * Built-in web interface that supports deep archaeological digs through |
| 34 | the project history. |
| 35 | * All network communication via |
| 36 | [http://en.wikipedia.org/wiki/HTTP | HTTP] with |
| 37 | [./quickstart.wiki#proxy | proxy support] |
| 38 | so that everything works from behind restrictive firewalls. |
| 39 | * Everything (client, server, and utilities) is included in a |
| 40 | single self-contained executable - trivial to install |
| 41 | * Server runs as [./quickstart.wiki#cgiserver | CGI], using |
| 42 | [./quickstart.wiki#inetdserver | inetd/xinetd] |
| 43 | or using its own |
| 44 | [./quickstart.wiki#serversetup | built-in, stand alone web server]. |
| 45 | * An entire project contained in single disk file |
| 46 | (an [http://www.sqlite.org/ | SQLite] database.) |
| 47 | * Uses an [./fileformat.wiki | enduring file format] that is |
| 48 | designed to be readable, searchable, and extensible by people |
| 49 | not yet born. |
| 50 | * Automatic [./selfcheck.wiki | self-check] |
| 51 | on repository changes makes it exceedingly |
| 52 | unlikely that data will ever be lost because of a software bug. |
| 53 | * Ridiculously easy to [./build.wiki | install] and |
| 54 | [./quickstart.wiki | operate]. |
| 55 | |
| 56 | User Links: |
| 57 | |
| 58 | * The [./concepts.wiki | concepts] behind fossil |
| 59 | * [./build.wiki | Building And Installing] |
| 60 | * [./quickstart.wiki | Quick Start] guide to using fossil |
| 61 | * Fossil supports [./embeddeddoc.wiki | embedded documentation] |
| 62 | that is versioned along with project source code. |
| 63 | * The [./selfcheck.wiki | automatic self-check] mechanism |
| 64 | helps insure project integrity. |
| 65 | * Fossil contains a [./wikitheory.wiki | built-in wiki]. |
| 66 | * There is a |
| 67 | [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] |
| 68 | available for discussing fossil issues. |
| 69 | * [./qandc.wiki | Questions & Criticisms] directed at fossil. |
| 70 | * Some (unfinished but expanding) extended |
| 71 | [./reference.wiki | reference documentation] for the fossil command line. |
| 72 | |
| 73 | Developer Links: |
| 74 | |
| 75 | * [./pop.wiki | Principles Of Operation] |
| 76 | * The [./fileformat.wiki | file format] used by every content |
| 77 | file stored in the repository. |
| 78 | * The [./delta_format.wiki | format of deltas] used to |
| 79 | efficiently store changes between file revisions. |
| 80 | * The [./delta_encoder_algorithm.wiki | encoder algorithm] used to |
| 81 | efficiently generate deltas. |
| 82 | * The [./sync.wiki | synchronization protocol]. |
| 83 | |
| 84 | Competing Projects: |
| 85 | |
| 86 | * [http://www.ditrack.org/ | DITrace] - A Distributed Issue Tracker |
| 87 | * [http://www.distract.wellquite.org/ | DisTract] |
| 88 | - Another distributed issue tracker based on |
| 89 | [http://www.monotone.ca/ | monotone]. |
| 90 | * [http://www.monotone.ca/ | Monotone] - distributed |
| 91 | SCM in a single-file executable with a single-file SQLite |
| 92 | database repository. |
| 93 |
+26
-3
| --- www/qandc.wiki | ||
| +++ www/qandc.wiki | ||
| @@ -18,11 +18,12 @@ | ||
| 18 | 18 | |
| 19 | 19 | <ol> |
| 20 | 20 | <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li> |
| 21 | 21 | <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li> |
| 22 | 22 | <li> Immutable artifacts </li> |
| 23 | - <li> Self-contained, stand-alone executable </li> | |
| 23 | + <li> Self-contained, stand-alone executable that can be run in | |
| 24 | + a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> | |
| 24 | 25 | <li> Simple, well-defined, |
| 25 | 26 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 26 | 27 | </ol> |
| 27 | 28 | </blockquote> |
| 28 | 29 | |
| @@ -78,12 +79,34 @@ | ||
| 78 | 79 | <b>It would be useful to have a separate application that |
| 79 | 80 | keeps the bug-tracking database in a versioned file. That file can |
| 80 | 81 | then be pushed and pulled along with the rest repository.</b> |
| 81 | 82 | |
| 82 | 83 | <blockquote> |
| 83 | -<p>This is addressed in the opening paragraphs of | |
| 84 | -the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. | |
| 84 | +<p>Fossil already <u>does</u> push and pull bugs along with the files | |
| 85 | +in your repository. | |
| 86 | +But fossil does <u>not</u> track bugs as files in the source tree. | |
| 87 | +That approach to bug tracking was rejected for three reasons:</p> | |
| 88 | + | |
| 89 | +<ol> | |
| 90 | +<li> Check-ins in fossil are immutable. So if | |
| 91 | + tickets were part of the check-in, then there would be no way to add | |
| 92 | + new tickets to a check-in as new bugs are discovered. | |
| 93 | + | |
| 94 | +<li> Any project of reasonable size and complexity will generate thousands | |
| 95 | + and thousands of tickets, and we do not want all those ticket files | |
| 96 | + cluttering the source tree. | |
| 97 | + | |
| 98 | +<li> We want tickets to be managed from the web interface and to have a | |
| 99 | + permission system that is distinct from check-in permissions. | |
| 100 | + In other words, we do not want to restrict the creation and editing | |
| 101 | + of tickets to developers with check-in privileges and an installed | |
| 102 | + copy of the fossil executable. Casual passers-by on the internet should | |
| 103 | + be permitted to create tickets. | |
| 104 | +</ol> | |
| 105 | + | |
| 106 | +<p>These points are reiterated in the opening paragraphs of | |
| 107 | +the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p> | |
| 85 | 108 | </blockquote> |
| 86 | 109 | |
| 87 | 110 | <b>Fossil is already the name of a plan9 versioned |
| 88 | 111 | append-only filesystem.</b> |
| 89 | 112 | |
| 90 | 113 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -18,11 +18,12 @@ | |
| 18 | |
| 19 | <ol> |
| 20 | <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li> |
| 21 | <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li> |
| 22 | <li> Immutable artifacts </li> |
| 23 | <li> Self-contained, stand-alone executable </li> |
| 24 | <li> Simple, well-defined, |
| 25 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 26 | </ol> |
| 27 | </blockquote> |
| 28 | |
| @@ -78,12 +79,34 @@ | |
| 78 | <b>It would be useful to have a separate application that |
| 79 | keeps the bug-tracking database in a versioned file. That file can |
| 80 | then be pushed and pulled along with the rest repository.</b> |
| 81 | |
| 82 | <blockquote> |
| 83 | <p>This is addressed in the opening paragraphs of |
| 84 | the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. |
| 85 | </blockquote> |
| 86 | |
| 87 | <b>Fossil is already the name of a plan9 versioned |
| 88 | append-only filesystem.</b> |
| 89 | |
| 90 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -18,11 +18,12 @@ | |
| 18 | |
| 19 | <ol> |
| 20 | <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li> |
| 21 | <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li> |
| 22 | <li> Immutable artifacts </li> |
| 23 | <li> Self-contained, stand-alone executable that can be run in |
| 24 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 25 | <li> Simple, well-defined, |
| 26 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 27 | </ol> |
| 28 | </blockquote> |
| 29 | |
| @@ -78,12 +79,34 @@ | |
| 79 | <b>It would be useful to have a separate application that |
| 80 | keeps the bug-tracking database in a versioned file. That file can |
| 81 | then be pushed and pulled along with the rest repository.</b> |
| 82 | |
| 83 | <blockquote> |
| 84 | <p>Fossil already <u>does</u> push and pull bugs along with the files |
| 85 | in your repository. |
| 86 | But fossil does <u>not</u> track bugs as files in the source tree. |
| 87 | That approach to bug tracking was rejected for three reasons:</p> |
| 88 | |
| 89 | <ol> |
| 90 | <li> Check-ins in fossil are immutable. So if |
| 91 | tickets were part of the check-in, then there would be no way to add |
| 92 | new tickets to a check-in as new bugs are discovered. |
| 93 | |
| 94 | <li> Any project of reasonable size and complexity will generate thousands |
| 95 | and thousands of tickets, and we do not want all those ticket files |
| 96 | cluttering the source tree. |
| 97 | |
| 98 | <li> We want tickets to be managed from the web interface and to have a |
| 99 | permission system that is distinct from check-in permissions. |
| 100 | In other words, we do not want to restrict the creation and editing |
| 101 | of tickets to developers with check-in privileges and an installed |
| 102 | copy of the fossil executable. Casual passers-by on the internet should |
| 103 | be permitted to create tickets. |
| 104 | </ol> |
| 105 | |
| 106 | <p>These points are reiterated in the opening paragraphs of |
| 107 | the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p> |
| 108 | </blockquote> |
| 109 | |
| 110 | <b>Fossil is already the name of a plan9 versioned |
| 111 | append-only filesystem.</b> |
| 112 | |
| 113 |
+46
-9
| --- www/wikitheory.wiki | ||
| +++ www/wikitheory.wiki | ||
| @@ -1,21 +1,38 @@ | ||
| 1 | -<h1>Wiki In <a href="index.wiki">Fossil</a></h1> | |
| 1 | +<h1>Wiki In [./index.wiki | Fossil]</h1> | |
| 2 | 2 | |
| 3 | -Fossil uses <a href="../../../wiki_rules">wiki markup</a> for many | |
| 4 | -things: | |
| 3 | +Fossil uses [/wiki_rules | wiki markup] for many things: | |
| 5 | 4 | |
| 6 | 5 | * Stand-alone wiki pages. |
| 7 | - * Description and comments in <a href="bugtheory.wiki">bug reports</a>. | |
| 6 | + * Description and comments in [./bugtheory.wiki | bug reports]. | |
| 8 | 7 | * Check-in comments. |
| 9 | - * <a href="embeddeddoc.wiki">Embedded documentation</a> files whose | |
| 8 | + * [./embeddeddoc.wiki | Embedded documentation] files whose | |
| 10 | 9 | name ends in "wiki". |
| 11 | 10 | |
| 12 | -The <a href="../../../wiki_rules">formatting rules</a> for fossil wiki | |
| 11 | +The [/wiki_rules | formatting rules] for fossil wiki | |
| 13 | 12 | are designed to be simple and intuitive. The idea is that wiki provides |
| 14 | 13 | paragaph breaks, numbered and bulletted lists, and hyperlinking for |
| 15 | 14 | simple documents together with a safe subset of HTML for more complex |
| 16 | 15 | formatting tasks. |
| 16 | + | |
| 17 | +Some commentators feel that the use of HTML is a mistake and that | |
| 18 | +fossil should use the markup language of the | |
| 19 | +<i>fill-in-your-favorite</i> wiki engine instead. That approach | |
| 20 | +was considered but was rejected for the following reasons: | |
| 21 | + | |
| 22 | + 1. There is no standard wiki markup language. Every wiki engine does | |
| 23 | + it a little differently. | |
| 24 | + | |
| 25 | + 2. The wiki markup used by fossil, though limited, is common to most | |
| 26 | + other wiki engines, is intuitive, and is sufficient for 90% of | |
| 27 | + all formatting tasks. | |
| 28 | + | |
| 29 | + 3. Where the fossil wiki markup language is insufficient, HTML is | |
| 30 | + used. HTML is a standard language familiar to most programmers so | |
| 31 | + there is nothing new to learn. And, though cumbersome, the HTML | |
| 32 | + does not need to be used very often so need not be a burden. | |
| 33 | + | |
| 17 | 34 | |
| 18 | 35 | <h2>Stand-alone Wiki Pages</h2> |
| 19 | 36 | |
| 20 | 37 | Each wiki page has its own revision history which is independent of |
| 21 | 38 | the sequence of baselines (check-ins). Wiki pages can branch and merge |
| @@ -30,9 +47,29 @@ | ||
| 30 | 47 | was checked in last. The other edit can be found in the history. The |
| 31 | 48 | file format will support merging the branches back together, but there |
| 32 | 49 | is no mechanism in the user interface (yet) to perform the merge. |
| 33 | 50 | |
| 34 | 51 | Every change to a wiki page is a separate |
| 35 | -<a href="fileformat.wiki">control artifact</a> | |
| 36 | -of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>. | |
| 52 | +[./fileformat.wiki | control artifact] | |
| 53 | +of type [./fileformat.wiki#wikichng | "Wiki Page"]. | |
| 54 | + | |
| 55 | +<h2>Embedded Documentation</h2> | |
| 56 | + | |
| 57 | +Files in the source tree that use the ".wiki" suffix can be accessed | |
| 58 | +and displayed using special URLs to the fossil server. This allows | |
| 59 | +project documentation to be stored in the source tree and accessed | |
| 60 | +online. (Details are descripted [./embeddeddoc.wiki | separately].) | |
| 61 | + | |
| 62 | +Some project prefer to store their documentation in wiki. There is nothing | |
| 63 | +wrong with that. But other projects prefer to keep documentation as part | |
| 64 | +of the source tree, so that it is versioned along with the source tree and | |
| 65 | +so that only developers with check-in privileges can change it. | |
| 66 | +Embedded documentation serves this latter purpose. Both forms of documentation | |
| 67 | +use the exact same wiki markup language. Some projects may choose to | |
| 68 | +use both forms of documentation at the same time. | |
| 69 | + | |
| 70 | +<h2>Bug-reports and check-in comments</h2> | |
| 37 | 71 | |
| 38 | -<i>To be continued...</i> | |
| 72 | +The comments on check-ins and the text in the descriptions of bug reports | |
| 73 | +both use wiki formatting. Exactly the same set of formatting rules apply. | |
| 74 | +There is never a need to learn one formatting language for documentation | |
| 75 | +and a different markup for bugs or for check-in comments. | |
| 39 | 76 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -1,21 +1,38 @@ | |
| 1 | <h1>Wiki In <a href="index.wiki">Fossil</a></h1> |
| 2 | |
| 3 | Fossil uses <a href="../../../wiki_rules">wiki markup</a> for many |
| 4 | things: |
| 5 | |
| 6 | * Stand-alone wiki pages. |
| 7 | * Description and comments in <a href="bugtheory.wiki">bug reports</a>. |
| 8 | * Check-in comments. |
| 9 | * <a href="embeddeddoc.wiki">Embedded documentation</a> files whose |
| 10 | name ends in "wiki". |
| 11 | |
| 12 | The <a href="../../../wiki_rules">formatting rules</a> for fossil wiki |
| 13 | are designed to be simple and intuitive. The idea is that wiki provides |
| 14 | paragaph breaks, numbered and bulletted lists, and hyperlinking for |
| 15 | simple documents together with a safe subset of HTML for more complex |
| 16 | formatting tasks. |
| 17 | |
| 18 | <h2>Stand-alone Wiki Pages</h2> |
| 19 | |
| 20 | Each wiki page has its own revision history which is independent of |
| 21 | the sequence of baselines (check-ins). Wiki pages can branch and merge |
| @@ -30,9 +47,29 @@ | |
| 30 | was checked in last. The other edit can be found in the history. The |
| 31 | file format will support merging the branches back together, but there |
| 32 | is no mechanism in the user interface (yet) to perform the merge. |
| 33 | |
| 34 | Every change to a wiki page is a separate |
| 35 | <a href="fileformat.wiki">control artifact</a> |
| 36 | of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>. |
| 37 | |
| 38 | <i>To be continued...</i> |
| 39 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -1,21 +1,38 @@ | |
| 1 | <h1>Wiki In [./index.wiki | Fossil]</h1> |
| 2 | |
| 3 | Fossil uses [/wiki_rules | wiki markup] for many things: |
| 4 | |
| 5 | * Stand-alone wiki pages. |
| 6 | * Description and comments in [./bugtheory.wiki | bug reports]. |
| 7 | * Check-in comments. |
| 8 | * [./embeddeddoc.wiki | Embedded documentation] files whose |
| 9 | name ends in "wiki". |
| 10 | |
| 11 | The [/wiki_rules | formatting rules] for fossil wiki |
| 12 | are designed to be simple and intuitive. The idea is that wiki provides |
| 13 | paragaph breaks, numbered and bulletted lists, and hyperlinking for |
| 14 | simple documents together with a safe subset of HTML for more complex |
| 15 | formatting tasks. |
| 16 | |
| 17 | Some commentators feel that the use of HTML is a mistake and that |
| 18 | fossil should use the markup language of the |
| 19 | <i>fill-in-your-favorite</i> wiki engine instead. That approach |
| 20 | was considered but was rejected for the following reasons: |
| 21 | |
| 22 | 1. There is no standard wiki markup language. Every wiki engine does |
| 23 | it a little differently. |
| 24 | |
| 25 | 2. The wiki markup used by fossil, though limited, is common to most |
| 26 | other wiki engines, is intuitive, and is sufficient for 90% of |
| 27 | all formatting tasks. |
| 28 | |
| 29 | 3. Where the fossil wiki markup language is insufficient, HTML is |
| 30 | used. HTML is a standard language familiar to most programmers so |
| 31 | there is nothing new to learn. And, though cumbersome, the HTML |
| 32 | does not need to be used very often so need not be a burden. |
| 33 | |
| 34 | |
| 35 | <h2>Stand-alone Wiki Pages</h2> |
| 36 | |
| 37 | Each wiki page has its own revision history which is independent of |
| 38 | the sequence of baselines (check-ins). Wiki pages can branch and merge |
| @@ -30,9 +47,29 @@ | |
| 47 | was checked in last. The other edit can be found in the history. The |
| 48 | file format will support merging the branches back together, but there |
| 49 | is no mechanism in the user interface (yet) to perform the merge. |
| 50 | |
| 51 | Every change to a wiki page is a separate |
| 52 | [./fileformat.wiki | control artifact] |
| 53 | of type [./fileformat.wiki#wikichng | "Wiki Page"]. |
| 54 | |
| 55 | <h2>Embedded Documentation</h2> |
| 56 | |
| 57 | Files in the source tree that use the ".wiki" suffix can be accessed |
| 58 | and displayed using special URLs to the fossil server. This allows |
| 59 | project documentation to be stored in the source tree and accessed |
| 60 | online. (Details are descripted [./embeddeddoc.wiki | separately].) |
| 61 | |
| 62 | Some project prefer to store their documentation in wiki. There is nothing |
| 63 | wrong with that. But other projects prefer to keep documentation as part |
| 64 | of the source tree, so that it is versioned along with the source tree and |
| 65 | so that only developers with check-in privileges can change it. |
| 66 | Embedded documentation serves this latter purpose. Both forms of documentation |
| 67 | use the exact same wiki markup language. Some projects may choose to |
| 68 | use both forms of documentation at the same time. |
| 69 | |
| 70 | <h2>Bug-reports and check-in comments</h2> |
| 71 | |
| 72 | The comments on check-ins and the text in the descriptions of bug reports |
| 73 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 74 | There is never a need to learn one formatting language for documentation |
| 75 | and a different markup for bugs or for check-in comments. |
| 76 |