Fossil SCM
Documentation updates.
Commit
9d10726d486380ad4ea012db56643291eaa13da1
Parent
3bc6d0b0c913b5c…
4 files changed
+22
-13
+1
+3
-3
+7
+22
-13
| --- www/bugtheory.wiki | ||
| +++ www/bugtheory.wiki | ||
| @@ -30,16 +30,16 @@ | ||
| 30 | 30 | <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>. |
| 31 | 31 | One or more ticket change artifacts are associated with each |
| 32 | 32 | ticket. A ticket is created by a ticket change artifact. |
| 33 | 33 | Each subsequent modification of the ticket is a separate artifact. |
| 34 | 34 | |
| 35 | -The "push", "pull", and "sync" algorithms shared ticket change artifacts | |
| 35 | +The "push", "pull", and "sync" algorithms share ticket change artifacts | |
| 36 | 36 | between repositories in the same way as every other artifact. In fact, |
| 37 | 37 | the sync algorithm has no knowledge of the meaning of the artifacts it |
| 38 | 38 | is syncing. As far as the sync algorithm is concerned, all artifacts are |
| 39 | -alike. After the sync has occurs, the individual repositories must try | |
| 40 | -to make sense of the meaning of the various artifacts for themselves. | |
| 39 | +alike. After the sync has occurs, the individual repositories must | |
| 40 | +make sense of the meaning of the various artifacts for themselves. | |
| 41 | 41 | |
| 42 | 42 | <h2>Interpretation Of Ticket Change Artifacts</h2> |
| 43 | 43 | |
| 44 | 44 | Every ticket change artifact contains (among other things) |
| 45 | 45 | |
| @@ -53,16 +53,16 @@ | ||
| 53 | 53 | ticket change artifact is encountered, values are either replaced |
| 54 | 54 | or appended, according to a flag on the name/value pair. The current |
| 55 | 55 | values for the fields of a ticket are the values that remain at the |
| 56 | 56 | end of the replay process. |
| 57 | 57 | |
| 58 | -To create a new ticket, on has merely to insert a ticket change | |
| 59 | -artifact with a randomly generated ticket UUID. The ticket UUID | |
| 60 | -is a random 40-character lower-case hexadecimal number. New | |
| 61 | -ticket UUIDs should be chosen using good randomness so that two | |
| 62 | -ore more users do not accidently cause a conflict by generating | |
| 63 | -the same UUID. The name/value pairs on the initial ticket change | |
| 58 | +To create a new ticket, one inserts a ticket change | |
| 59 | +artifact with a new UUID. The ticket UUID | |
| 60 | +is a random 40-character lower-case hexadecimal number. The "tktnew" | |
| 61 | +page in the fossil web interface creates new ticket UUIDs | |
| 62 | +using a good source of randomness to insure uniqueness. | |
| 63 | +The name/value pairs on the initial ticket change | |
| 64 | 64 | artifact are the initial values for the fields in the ticket. |
| 65 | 65 | |
| 66 | 66 | Amending a ticket means simply creating a new artifact with the |
| 67 | 67 | same ticket UUID and with name/value pairs for those fields which |
| 68 | 68 | are changing. Fields of the ticket which are not being modified |
| @@ -98,15 +98,24 @@ | ||
| 98 | 98 | Each repository defines its own TICKET table in its database. There is |
| 99 | 99 | one row in the TICKET table for each unique ticket UUID. The |
| 100 | 100 | names of columns in the TICKET table correspond to the names in |
| 101 | 101 | the name/value pairs of ticket change artifacts. When running the replay |
| 102 | 102 | algorithm, if a name/value pair is seen which has no corresponding column |
| 103 | -in the TICKET table, then that name/value pair is ignored. | |
| 103 | +in the TICKET table, then that name/value pair is ignored. Columns can | |
| 104 | +be added or removed from the TICKET table at any time. Whenever the | |
| 105 | +TICKET table is modified, the replay algorithm automatically reruns | |
| 106 | +to repopulate the table using the new column names. Note that the TICKET | |
| 107 | +table schema and content is part of the local state of a respository | |
| 108 | +and is not shared with other repositories during a sync, push, or pull. | |
| 104 | 109 | |
| 105 | 110 | Each repository also defines scripts used to generate web pages for |
| 106 | 111 | creating new tickets, viewing existing tickets, and modifying an |
| 107 | 112 | existing ticket. These scripts consist of HTML with an embedded |
| 108 | -scripts written an a TCL-like language called "TH1". Each fossil | |
| 109 | -repository is create with default scripts. There is currently no | |
| 113 | +scripts written an a TCL-like language called "TH1". Every new fossil | |
| 114 | +repository is created with default scripts. There is currently no | |
| 110 | 115 | documentation on the TH1 langauage. Administrators wishing to |
| 111 | 116 | customize their ticket entry, viewing, and editing screens should |
| 112 | -modify the default scripts to suit their needs. | |
| 117 | +modify the default scripts to suit their needs. These screen generator | |
| 118 | +scripts are part of the local state of a repository and are not shared | |
| 119 | +with other repositories during a sync, push, or pull. | |
| 120 | + | |
| 121 | +<i>To be continued...</i> | |
| 113 | 122 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -30,16 +30,16 @@ | |
| 30 | <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>. |
| 31 | One or more ticket change artifacts are associated with each |
| 32 | ticket. A ticket is created by a ticket change artifact. |
| 33 | Each subsequent modification of the ticket is a separate artifact. |
| 34 | |
| 35 | The "push", "pull", and "sync" algorithms shared ticket change artifacts |
| 36 | between repositories in the same way as every other artifact. In fact, |
| 37 | the sync algorithm has no knowledge of the meaning of the artifacts it |
| 38 | is syncing. As far as the sync algorithm is concerned, all artifacts are |
| 39 | alike. After the sync has occurs, the individual repositories must try |
| 40 | to make sense of the meaning of the various artifacts for themselves. |
| 41 | |
| 42 | <h2>Interpretation Of Ticket Change Artifacts</h2> |
| 43 | |
| 44 | Every ticket change artifact contains (among other things) |
| 45 | |
| @@ -53,16 +53,16 @@ | |
| 53 | ticket change artifact is encountered, values are either replaced |
| 54 | or appended, according to a flag on the name/value pair. The current |
| 55 | values for the fields of a ticket are the values that remain at the |
| 56 | end of the replay process. |
| 57 | |
| 58 | To create a new ticket, on has merely to insert a ticket change |
| 59 | artifact with a randomly generated ticket UUID. The ticket UUID |
| 60 | is a random 40-character lower-case hexadecimal number. New |
| 61 | ticket UUIDs should be chosen using good randomness so that two |
| 62 | ore more users do not accidently cause a conflict by generating |
| 63 | the same UUID. The name/value pairs on the initial ticket change |
| 64 | artifact are the initial values for the fields in the ticket. |
| 65 | |
| 66 | Amending a ticket means simply creating a new artifact with the |
| 67 | same ticket UUID and with name/value pairs for those fields which |
| 68 | are changing. Fields of the ticket which are not being modified |
| @@ -98,15 +98,24 @@ | |
| 98 | Each repository defines its own TICKET table in its database. There is |
| 99 | one row in the TICKET table for each unique ticket UUID. The |
| 100 | names of columns in the TICKET table correspond to the names in |
| 101 | the name/value pairs of ticket change artifacts. When running the replay |
| 102 | algorithm, if a name/value pair is seen which has no corresponding column |
| 103 | in the TICKET table, then that name/value pair is ignored. |
| 104 | |
| 105 | Each repository also defines scripts used to generate web pages for |
| 106 | creating new tickets, viewing existing tickets, and modifying an |
| 107 | existing ticket. These scripts consist of HTML with an embedded |
| 108 | scripts written an a TCL-like language called "TH1". Each fossil |
| 109 | repository is create with default scripts. There is currently no |
| 110 | documentation on the TH1 langauage. Administrators wishing to |
| 111 | customize their ticket entry, viewing, and editing screens should |
| 112 | modify the default scripts to suit their needs. |
| 113 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -30,16 +30,16 @@ | |
| 30 | <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>. |
| 31 | One or more ticket change artifacts are associated with each |
| 32 | ticket. A ticket is created by a ticket change artifact. |
| 33 | Each subsequent modification of the ticket is a separate artifact. |
| 34 | |
| 35 | The "push", "pull", and "sync" algorithms share ticket change artifacts |
| 36 | between repositories in the same way as every other artifact. In fact, |
| 37 | the sync algorithm has no knowledge of the meaning of the artifacts it |
| 38 | is syncing. As far as the sync algorithm is concerned, all artifacts are |
| 39 | alike. After the sync has occurs, the individual repositories must |
| 40 | make sense of the meaning of the various artifacts for themselves. |
| 41 | |
| 42 | <h2>Interpretation Of Ticket Change Artifacts</h2> |
| 43 | |
| 44 | Every ticket change artifact contains (among other things) |
| 45 | |
| @@ -53,16 +53,16 @@ | |
| 53 | ticket change artifact is encountered, values are either replaced |
| 54 | or appended, according to a flag on the name/value pair. The current |
| 55 | values for the fields of a ticket are the values that remain at the |
| 56 | end of the replay process. |
| 57 | |
| 58 | To create a new ticket, one inserts a ticket change |
| 59 | artifact with a new UUID. The ticket UUID |
| 60 | is a random 40-character lower-case hexadecimal number. The "tktnew" |
| 61 | page in the fossil web interface creates new ticket UUIDs |
| 62 | using a good source of randomness to insure uniqueness. |
| 63 | The name/value pairs on the initial ticket change |
| 64 | artifact are the initial values for the fields in the ticket. |
| 65 | |
| 66 | Amending a ticket means simply creating a new artifact with the |
| 67 | same ticket UUID and with name/value pairs for those fields which |
| 68 | are changing. Fields of the ticket which are not being modified |
| @@ -98,15 +98,24 @@ | |
| 98 | Each repository defines its own TICKET table in its database. There is |
| 99 | one row in the TICKET table for each unique ticket UUID. The |
| 100 | names of columns in the TICKET table correspond to the names in |
| 101 | the name/value pairs of ticket change artifacts. When running the replay |
| 102 | algorithm, if a name/value pair is seen which has no corresponding column |
| 103 | in the TICKET table, then that name/value pair is ignored. Columns can |
| 104 | be added or removed from the TICKET table at any time. Whenever the |
| 105 | TICKET table is modified, the replay algorithm automatically reruns |
| 106 | to repopulate the table using the new column names. Note that the TICKET |
| 107 | table schema and content is part of the local state of a respository |
| 108 | and is not shared with other repositories during a sync, push, or pull. |
| 109 | |
| 110 | Each repository also defines scripts used to generate web pages for |
| 111 | creating new tickets, viewing existing tickets, and modifying an |
| 112 | existing ticket. These scripts consist of HTML with an embedded |
| 113 | scripts written an a TCL-like language called "TH1". Every new fossil |
| 114 | repository is created with default scripts. There is currently no |
| 115 | documentation on the TH1 langauage. Administrators wishing to |
| 116 | customize their ticket entry, viewing, and editing screens should |
| 117 | modify the default scripts to suit their needs. These screen generator |
| 118 | scripts are part of the local state of a repository and are not shared |
| 119 | with other repositories during a sync, push, or pull. |
| 120 | |
| 121 | <i>To be continued...</i> |
| 122 |
+1
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -268,10 +268,11 @@ | ||
| 268 | 268 | |
| 269 | 269 | <p>Some tags have special meaning. The "comment" tag when applied |
| 270 | 270 | to a baseline will override the check-in comment of that baseline |
| 271 | 271 | for display purposes.</p> |
| 272 | 272 | |
| 273 | +<a name="wikichng"></a> | |
| 273 | 274 | <h2>4.0 Wiki Pages</h2> |
| 274 | 275 | |
| 275 | 276 | <p>A wiki page is an artifact with a format similar to manifests, |
| 276 | 277 | clusters, and control artifacts. The artifact is divided into |
| 277 | 278 | cards by newline characters. The format of each card is as in |
| 278 | 279 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -268,10 +268,11 @@ | |
| 268 | |
| 269 | <p>Some tags have special meaning. The "comment" tag when applied |
| 270 | to a baseline will override the check-in comment of that baseline |
| 271 | for display purposes.</p> |
| 272 | |
| 273 | <h2>4.0 Wiki Pages</h2> |
| 274 | |
| 275 | <p>A wiki page is an artifact with a format similar to manifests, |
| 276 | clusters, and control artifacts. The artifact is divided into |
| 277 | cards by newline characters. The format of each card is as in |
| 278 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -268,10 +268,11 @@ | |
| 268 | |
| 269 | <p>Some tags have special meaning. The "comment" tag when applied |
| 270 | to a baseline will override the check-in comment of that baseline |
| 271 | for display purposes.</p> |
| 272 | |
| 273 | <a name="wikichng"></a> |
| 274 | <h2>4.0 Wiki Pages</h2> |
| 275 | |
| 276 | <p>A wiki page is an artifact with a format similar to manifests, |
| 277 | clusters, and control artifacts. The artifact is divided into |
| 278 | cards by newline characters. The format of each card is as in |
| 279 |
+3
-3
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -2,11 +2,11 @@ | ||
| 2 | 2 | |
| 3 | 3 | <p> |
| 4 | 4 | Fossil is a new |
| 5 | 5 | <a href="http://en.wikipedia.org/wiki/Revision_control"> |
| 6 | 6 | distributed software revision control system</a> that includes an integrated |
| 7 | -<a href="../../../wiki_rules">wiki</a> and an integrated | |
| 7 | +<a href="wikitheory.wiki">wiki</a> and an integrated | |
| 8 | 8 | <a href="bugtheory.wiki">bug-tracking system</a> all in a single, |
| 9 | 9 | easy-to-use, stand-alone executable. |
| 10 | 10 | Fossil is |
| 11 | 11 | <a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a> |
| 12 | 12 | since 2007-07-21 on |
| @@ -29,11 +29,11 @@ | ||
| 29 | 29 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 30 | 30 | <a href="http://subversion.tigris.org/">subversion</a>), |
| 31 | 31 | or operations on local repositories, |
| 32 | 32 | or all three at the same time</li> |
| 33 | 33 | <li>Integrated <a href="bugtheory.wiki">bug tracking</a> and |
| 34 | -<a href="../../../wiki_rules">wiki</a>, inspired by | |
| 34 | +<a href="wikitheory.wiki">wiki</a>, inspired by | |
| 35 | 35 | <a href="http://www.cvstrac.org/">CVSTrac</a> and |
| 36 | 36 | <a href="http://www.edgewall.com/trac/">Trac</a> but enhanced to |
| 37 | 37 | support distributed, disconnected operation.</li> |
| 38 | 38 | <li>Built-in web interface that supports deep archaeological digs through |
| 39 | 39 | the project history.</li> |
| @@ -91,11 +91,11 @@ | ||
| 91 | 91 | <li><a href="quickstart.wiki">Quick Start</a> guide to using fossil |
| 92 | 92 | <li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a> |
| 93 | 93 | that is versioned along with project source code.</li> |
| 94 | 94 | <li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism |
| 95 | 95 | helps insure project integrity.</li> |
| 96 | -<li>Fossil contains a <a href="../../../wiki">built-in wiki</a>.</li> | |
| 96 | +<li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li> | |
| 97 | 97 | <li>There is a |
| 98 | 98 | <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 99 | 99 | mailing list</a> available for discussing fossil issues.</li> |
| 100 | 100 | </ul> |
| 101 | 101 | |
| 102 | 102 | |
| 103 | 103 | ADDED www/wikitheory.wiki |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | <p> |
| 4 | Fossil is a new |
| 5 | <a href="http://en.wikipedia.org/wiki/Revision_control"> |
| 6 | distributed software revision control system</a> that includes an integrated |
| 7 | <a href="../../../wiki_rules">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/fossil/timeline">self-hosting</a> |
| 12 | since 2007-07-21 on |
| @@ -29,11 +29,11 @@ | |
| 29 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 30 | <a href="http://subversion.tigris.org/">subversion</a>), |
| 31 | or operations on local repositories, |
| 32 | or all three at the same time</li> |
| 33 | <li>Integrated <a href="bugtheory.wiki">bug tracking</a> and |
| 34 | <a href="../../../wiki_rules">wiki</a>, inspired by |
| 35 | <a href="http://www.cvstrac.org/">CVSTrac</a> and |
| 36 | <a href="http://www.edgewall.com/trac/">Trac</a> but enhanced to |
| 37 | support distributed, disconnected operation.</li> |
| 38 | <li>Built-in web interface that supports deep archaeological digs through |
| 39 | the project history.</li> |
| @@ -91,11 +91,11 @@ | |
| 91 | <li><a href="quickstart.wiki">Quick Start</a> guide to using fossil |
| 92 | <li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a> |
| 93 | that is versioned along with project source code.</li> |
| 94 | <li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism |
| 95 | helps insure project integrity.</li> |
| 96 | <li>Fossil contains a <a href="../../../wiki">built-in wiki</a>.</li> |
| 97 | <li>There is a |
| 98 | <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 99 | mailing list</a> available for discussing fossil issues.</li> |
| 100 | </ul> |
| 101 | |
| 102 | |
| 103 | DDED www/wikitheory.wiki |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | <p> |
| 4 | Fossil is a new |
| 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/fossil/timeline">self-hosting</a> |
| 12 | since 2007-07-21 on |
| @@ -29,11 +29,11 @@ | |
| 29 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 30 | <a href="http://subversion.tigris.org/">subversion</a>), |
| 31 | or operations on local repositories, |
| 32 | or all three at the same time</li> |
| 33 | <li>Integrated <a href="bugtheory.wiki">bug tracking</a> and |
| 34 | <a href="wikitheory.wiki">wiki</a>, inspired by |
| 35 | <a href="http://www.cvstrac.org/">CVSTrac</a> and |
| 36 | <a href="http://www.edgewall.com/trac/">Trac</a> but enhanced to |
| 37 | support distributed, disconnected operation.</li> |
| 38 | <li>Built-in web interface that supports deep archaeological digs through |
| 39 | the project history.</li> |
| @@ -91,11 +91,11 @@ | |
| 91 | <li><a href="quickstart.wiki">Quick Start</a> guide to using fossil |
| 92 | <li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a> |
| 93 | that is versioned along with project source code.</li> |
| 94 | <li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism |
| 95 | helps insure project integrity.</li> |
| 96 | <li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li> |
| 97 | <li>There is a |
| 98 | <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 99 | mailing list</a> available for discussing fossil issues.</li> |
| 100 | </ul> |
| 101 | |
| 102 | |
| 103 | DDED www/wikitheory.wiki |
+7
| --- a/www/wikitheory.wiki | ||
| +++ b/www/wikitheory.wiki | ||
| @@ -0,0 +1,7 @@ | ||
| 1 | +<h1>Wiki In <a href="index.wiki">Fossil</a></h1> | |
| 2 | + | |
| 3 | +Fossil uses <a href="../../../wiki_rules<a href="bugtheory.wik * <a href=""></a><a href="../../../wiki_<a href="fileformat.wiki">control artifact</a> | |
| 4 | +of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>. | |
| 5 | + | |
| 6 | +<i>To be continued...</i> | |
| 7 | +sly |
| --- a/www/wikitheory.wiki | |
| +++ b/www/wikitheory.wiki | |
| @@ -0,0 +1,7 @@ | |
| --- a/www/wikitheory.wiki | |
| +++ b/www/wikitheory.wiki | |
| @@ -0,0 +1,7 @@ | |
| 1 | <h1>Wiki In <a href="index.wiki">Fossil</a></h1> |
| 2 | |
| 3 | Fossil uses <a href="../../../wiki_rules<a href="bugtheory.wik * <a href=""></a><a href="../../../wiki_<a href="fileformat.wiki">control artifact</a> |
| 4 | of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>. |
| 5 | |
| 6 | <i>To be continued...</i> |
| 7 | sly |