Overview
| SHA1 Hash: | 6ba52ae7619f9ea57fb295db7fb626c051a1b841 |
|---|---|
| Date: | 2009-02-21 13:09:40 |
| User: | drh |
| Comment: | Documentation tweaks. No changes to code. |
| 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 [062a9acd52] to [d140a990b1].
@@ -38,10 +38,13 @@ is syncing. As far as the sync algorithm is concerned, all artifacts are 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> + +<i>Note: The following is implementation detail which can be safely ignored by +casual users of fossil.</i> Every ticket change artifact contains (among other things) * a timestamp, * a ticket ID, and
Modified www/embeddeddoc.wiki from [f65cddb5e8] to [43544f7566].
@@ -43,19 +43,22 @@ then the <i><baseurl></i> is usually <b>http://localhost:8080/</b>. The <i><version></i> is any unique prefix of the check-in ID for the check-in containing the documentation you want to access. +Or <i><version></i> can be the name of a +[./branching.wiki | branch] in order to show +the documentation for the latest version of that branch. Or <i><version></i> can be one of the keywords "<b>tip</b>" or "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently checked-in. This is useful if you want to see the very latest version of the documentation. The "<b>ckout</b>" keywords means to pull the documentation file from the local source tree on disk, not from the any check-in. The "<b>ckout</b>" keyword normally only works when you start your server using the "<b>fossil server</b>" or "<b>fossil ui</b>" -command line and is indented to show what the documentation you are currently +command line and is intended to show what the documentation you are currently editing looks like before you check it in. Finally, the <i><filename></i> element of the URL is the full pathname of the documentation file starting from the root of the source tree.
Modified www/qandc.wiki from [36405b750a] to [c8c3e7e8fe].
@@ -24,10 +24,11 @@
<li> Immutable artifacts </li>
<li> Self-contained, stand-alone executable that can be run in
a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
<li> Simple, well-defined,
<a href="fileformat.wiki">enduring file format</a> </li>
+ <li> Integrated <a href="webui.wiki">web interface</a> </li>
</ol>
</blockquote>
<b>Why should I use this rather than Trac?</b>
Modified www/webui.wiki from [5308e376e1] to [d42ebb3c01].
@@ -45,11 +45,11 @@ from within an open check-out, you can omit the repository name: <b>fossil ui</b> The latter case is a very useful short-cut when you are working on a -fossil project and what to quickly do some work with the interface. +fossil project and you what to quickly do some work with the web interface. Notice that fossil automatically finds an unused TCP port to run the server own and automatically points your web browser to the correct URL. So there is never any fumbling around trying to find an open port or to type arcane strings into your browser URL entry box. The interface just pops right up, ready to run.
Modified www/wikitheory.wiki from [d324ca8133] to [7cce5ff736].
@@ -27,11 +27,11 @@
all formatting tasks.
3. Where the fossil wiki markup language is insufficient, HTML is
used. HTML is a standard language familiar to most programmers so
there is nothing new to learn. And, though cumbersome, the HTML
- does not need to be used very often so need not be a burden.
+ does not need to be used very often so is not a burden.
<h2>Stand-alone Wiki Pages</h2>
Each wiki page has its own revision history which is independent of
@@ -40,11 +40,11 @@
no mechanism in the user interface to support branching and merging.
The current implementation of the wiki shows the version of the wiki
page 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,
+page on separate repositories and 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.
@@ -63,13 +63,15 @@
wrong with that. But other projects prefer to keep documentation as part
of the source tree, so that it is versioned along with the source tree and
so that only developers with check-in privileges can change it.
Embedded documentation serves this latter purpose. Both forms of documentation
use the exact same wiki markup language. Some projects may choose to
-use both forms of documentation at the same time.
+use both forms of documentation at the same time. Because the same
+format is used, it is trival to move file from wiki to embedded documentation
+or back again as the project evolves.
<h2>Bug-reports and check-in comments</h2>
The comments on check-ins and the text in the descriptions of bug reports
both use wiki formatting. Exactly the same set of formatting rules apply.
There is never a need to learn one formatting language for documentation
and a different markup for bugs or for check-in comments.