Overview
| SHA1 Hash: | 9d10726d486380ad4ea012db56643291eaa13da1 |
|---|---|
| Date: | 2008-07-29 13:07:17 |
| User: | drh |
| Comment: | Documentation updates. |
| Timelines: | ancestors | descendants | both | trunk |
| Other Links: | files | ZIP archive | manifest |
Tags And Properties
- branch=trunk inherited from [a28c83647d]
- sym-trunk inherited from [a28c83647d]
Changes
[hide diffs]Modified www/bugtheory.wiki from [6a29c06018] to [fa19049169].
@@ -30,16 +30,16 @@ <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>. One or more ticket change artifacts are associated with each ticket. A ticket is created by a ticket change artifact. Each subsequent modification of the ticket is a separate artifact. -The "push", "pull", and "sync" algorithms shared ticket change artifacts +The "push", "pull", and "sync" algorithms share ticket change artifacts between repositories in the same way as every other artifact. In fact, the sync algorithm has no knowledge of the meaning of the artifacts it is syncing. As far as the sync algorithm is concerned, all artifacts are -alike. After the sync has occurs, the individual repositories must try -to make sense of the meaning of the various artifacts for themselves. +alike. After the sync has occurs, the individual repositories must +make sense of the meaning of the various artifacts for themselves. <h2>Interpretation Of Ticket Change Artifacts</h2> Every ticket change artifact contains (among other things) @@ -53,16 +53,16 @@ ticket change artifact is encountered, values are either replaced or appended, according to a flag on the name/value pair. The current values for the fields of a ticket are the values that remain at the end of the replay process. -To create a new ticket, on has merely to insert a ticket change -artifact with a randomly generated ticket UUID. The ticket UUID -is a random 40-character lower-case hexadecimal number. New -ticket UUIDs should be chosen using good randomness so that two -ore more users do not accidently cause a conflict by generating -the same UUID. The name/value pairs on the initial ticket change +To create a new ticket, one inserts a ticket change +artifact with a new UUID. The ticket UUID +is a random 40-character lower-case hexadecimal number. The "tktnew" +page in the fossil web interface creates new ticket UUIDs +using a good source of randomness to insure uniqueness. +The name/value pairs on the initial ticket change artifact are the initial values for the fields in the ticket. Amending a ticket means simply creating a new artifact with the same ticket UUID and with name/value pairs for those fields which are changing. Fields of the ticket which are not being modified @@ -98,15 +98,24 @@ Each repository defines its own TICKET table in its database. There is one row in the TICKET table for each unique ticket UUID. The names of columns in the TICKET table correspond to the names in the name/value pairs of ticket change artifacts. When running the replay algorithm, if a name/value pair is seen which has no corresponding column -in the TICKET table, then that name/value pair is ignored. +in the TICKET table, then that name/value pair is ignored. Columns can +be added or removed from the TICKET table at any time. Whenever the +TICKET table is modified, the replay algorithm automatically reruns +to repopulate the table using the new column names. Note that the TICKET +table schema and content is part of the local state of a respository +and is not shared with other repositories during a sync, push, or pull. Each repository also defines scripts used to generate web pages for creating new tickets, viewing existing tickets, and modifying an existing ticket. These scripts consist of HTML with an embedded -scripts written an a TCL-like language called "TH1". Each fossil -repository is create with default scripts. There is currently no +scripts written an a TCL-like language called "TH1". Every new fossil +repository is created with default scripts. There is currently no documentation on the TH1 langauage. Administrators wishing to customize their ticket entry, viewing, and editing screens should -modify the default scripts to suit their needs. +modify the default scripts to suit their needs. These screen generator +scripts are part of the local state of a repository and are not shared +with other repositories during a sync, push, or pull. + +<i>To be continued...</i>
Modified www/fileformat.wiki from [3dee4db541] to [51b55c19f0].
@@ -268,10 +268,11 @@ <p>Some tags have special meaning. The "comment" tag when applied to a baseline will override the check-in comment of that baseline for display purposes.</p> +<a name="wikichng"></a> <h2>4.0 Wiki Pages</h2> <p>A wiki page is an artifact with a format similar to manifests, clusters, and control artifacts. The artifact is divided into cards by newline characters. The format of each card is as in
Modified www/index.wiki from [997d5488af] to [23a1400897].
@@ -2,11 +2,11 @@
<p>
Fossil is a new
<a href="http://en.wikipedia.org/wiki/Revision_control">
distributed software revision control system</a> that includes an integrated
-<a href="../../../wiki_rules">wiki</a> and an integrated
+<a href="wikitheory.wiki">wiki</a> and an integrated
<a href="bugtheory.wiki">bug-tracking system</a> all in a single,
easy-to-use, stand-alone executable.
Fossil is
<a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a>
since 2007-07-21 on
@@ -29,11 +29,11 @@
<a href="http://www.nongnu.org/cvs/">CVS</a> or
<a href="http://subversion.tigris.org/">subversion</a>),
or operations on local repositories,
or all three at the same time</li>
<li>Integrated <a href="bugtheory.wiki">bug tracking</a> and
-<a href="../../../wiki_rules">wiki</a>, inspired by
+<a href="wikitheory.wiki">wiki</a>, inspired by
<a href="http://www.cvstrac.org/">CVSTrac</a> and
<a href="http://www.edgewall.com/trac/">Trac</a> but enhanced to
support distributed, disconnected operation.</li>
<li>Built-in web interface that supports deep archaeological digs through
the project history.</li>
@@ -91,11 +91,11 @@
<li><a href="quickstart.wiki">Quick Start</a> guide to using fossil
<li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a>
that is versioned along with project source code.</li>
<li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism
helps insure project integrity.</li>
-<li>Fossil contains a <a href="../../../wiki">built-in wiki</a>.</li>
+<li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li>
<li>There is a
<a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
mailing list</a> available for discussing fossil issues.</li>
</ul>
Added www/wikitheory.wiki version [5fbe6f3335]
@@ -1,1 +1,38 @@ +<h1>Wiki In <a href="index.wiki">Fossil</a></h1> + +Fossil uses <a href="../../../wiki_rules">wiki markup</a> for many +things: + + * Stand-alone wiki pages. + * Description and comments in <a href="bugtheory.wiki">bug reports</a>. + * Check-in comments. + * <a href="embeddeddoc.wiki">Embedded documentation</a> files whose + name ends in "wiki". + +The <a href="../../../wiki_rules">formatting rules</a> for fossil wiki +are designed to be simple and intuitive. The idea is that wiki provides +paragaph breaks, numbered and bulletted lists, and hyperlinking for +simple documents together with a safe subset of HTML for more complex +formatting tasks. + +<h2>Stand-alone Wiki Pages</h2> + +Each wiki page has its own revision history which is independent of +the sequence of baselines (check-ins). Wiki pages can branch and merge +just like baselines, though as of this writing (2008-07-29) there is +no mechanism in the user interface to support branching and merging. +The currently implementation of the wiki shows the version of the wiki +pages that has the most recent timestamp. + +In other words, if two users make unrelated changes to the same wiki +page on separate repositories, then those repositories are synced, +the wiki page will fork. The web interface will display whichever edit +was checked in last. The other edit can be found in the history. The +file format will support merging the branches back together, but there +is no mechanism in the user interface (yet) to perform the merge. + +Every change to a wiki page is a separate +<a href="fileformat.wiki">control artifact</a> +of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>. +<i>To be continued...</i>