Fossil SCM
Documentation tweaks. No changes to code.
Commit
6ba52ae7619f9ea57fb295db7fb626c051a1b841
Parent
bc857ecd923b8a6…
5 files changed
+3
+4
-1
+1
+1
-1
+5
-3
+3
| --- www/bugtheory.wiki | ||
| +++ www/bugtheory.wiki | ||
| @@ -38,10 +38,13 @@ | ||
| 38 | 38 | is syncing. As far as the sync algorithm is concerned, all artifacts are |
| 39 | 39 | alike. After the sync has occurs, the individual repositories must |
| 40 | 40 | make sense of the meaning of the various artifacts for themselves. |
| 41 | 41 | |
| 42 | 42 | <h2>Interpretation Of Ticket Change Artifacts</h2> |
| 43 | + | |
| 44 | +<i>Note: The following is implementation detail which can be safely ignored by | |
| 45 | +casual users of fossil.</i> | |
| 43 | 46 | |
| 44 | 47 | Every ticket change artifact contains (among other things) |
| 45 | 48 | |
| 46 | 49 | * a timestamp, |
| 47 | 50 | * a ticket ID, and |
| 48 | 51 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -38,10 +38,13 @@ | |
| 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 | |
| 46 | * a timestamp, |
| 47 | * a ticket ID, and |
| 48 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -38,10 +38,13 @@ | |
| 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 | <i>Note: The following is implementation detail which can be safely ignored by |
| 45 | casual users of fossil.</i> |
| 46 | |
| 47 | Every ticket change artifact contains (among other things) |
| 48 | |
| 49 | * a timestamp, |
| 50 | * a ticket ID, and |
| 51 |
+4
-1
| --- www/embeddeddoc.wiki | ||
| +++ www/embeddeddoc.wiki | ||
| @@ -43,19 +43,22 @@ | ||
| 43 | 43 | then the <i><baseurl></i> is usually |
| 44 | 44 | <b>http://localhost:8080/</b>. |
| 45 | 45 | |
| 46 | 46 | The <i><version></i> is any unique prefix of the check-in ID for |
| 47 | 47 | the check-in containing the documentation you want to access. |
| 48 | +Or <i><version></i> can be the name of a | |
| 49 | +[./branching.wiki | branch] in order to show | |
| 50 | +the documentation for the latest version of that branch. | |
| 48 | 51 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 49 | 52 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 50 | 53 | checked-in. This is useful if you want to see the very latest |
| 51 | 54 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 52 | 55 | pull the documentation file from the local source tree on disk, not |
| 53 | 56 | from the any check-in. The "<b>ckout</b>" keyword normally |
| 54 | 57 | only works when you start your server using the "<b>fossil server</b>" |
| 55 | 58 | or "<b>fossil ui</b>" |
| 56 | -command line and is indented to show what the documentation you are currently | |
| 59 | +command line and is intended to show what the documentation you are currently | |
| 57 | 60 | editing looks like before you check it in. |
| 58 | 61 | |
| 59 | 62 | Finally, the <i><filename></i> element of the URL is the full |
| 60 | 63 | pathname of the documentation file starting from the root of the source |
| 61 | 64 | tree. |
| 62 | 65 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -43,19 +43,22 @@ | |
| 43 | then the <i><baseurl></i> is usually |
| 44 | <b>http://localhost:8080/</b>. |
| 45 | |
| 46 | The <i><version></i> is any unique prefix of the check-in ID for |
| 47 | the check-in containing the documentation you want to access. |
| 48 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 49 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 50 | checked-in. This is useful if you want to see the very latest |
| 51 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 52 | pull the documentation file from the local source tree on disk, not |
| 53 | from the any check-in. The "<b>ckout</b>" keyword normally |
| 54 | only works when you start your server using the "<b>fossil server</b>" |
| 55 | or "<b>fossil ui</b>" |
| 56 | command line and is indented to show what the documentation you are currently |
| 57 | editing looks like before you check it in. |
| 58 | |
| 59 | Finally, the <i><filename></i> element of the URL is the full |
| 60 | pathname of the documentation file starting from the root of the source |
| 61 | tree. |
| 62 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -43,19 +43,22 @@ | |
| 43 | then the <i><baseurl></i> is usually |
| 44 | <b>http://localhost:8080/</b>. |
| 45 | |
| 46 | The <i><version></i> is any unique prefix of the check-in ID for |
| 47 | the check-in containing the documentation you want to access. |
| 48 | Or <i><version></i> can be the name of a |
| 49 | [./branching.wiki | branch] in order to show |
| 50 | the documentation for the latest version of that branch. |
| 51 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 52 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 53 | checked-in. This is useful if you want to see the very latest |
| 54 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 55 | pull the documentation file from the local source tree on disk, not |
| 56 | from the any check-in. The "<b>ckout</b>" keyword normally |
| 57 | only works when you start your server using the "<b>fossil server</b>" |
| 58 | or "<b>fossil ui</b>" |
| 59 | command line and is intended to show what the documentation you are currently |
| 60 | editing looks like before you check it in. |
| 61 | |
| 62 | Finally, the <i><filename></i> element of the URL is the full |
| 63 | pathname of the documentation file starting from the root of the source |
| 64 | tree. |
| 65 |
+1
| --- www/qandc.wiki | ||
| +++ www/qandc.wiki | ||
| @@ -24,10 +24,11 @@ | ||
| 24 | 24 | <li> Immutable artifacts </li> |
| 25 | 25 | <li> Self-contained, stand-alone executable that can be run in |
| 26 | 26 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 27 | 27 | <li> Simple, well-defined, |
| 28 | 28 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 29 | + <li> Integrated <a href="webui.wiki">web interface</a> </li> | |
| 29 | 30 | </ol> |
| 30 | 31 | </blockquote> |
| 31 | 32 | |
| 32 | 33 | <b>Why should I use this rather than Trac?</b> |
| 33 | 34 | |
| 34 | 35 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -24,10 +24,11 @@ | |
| 24 | <li> Immutable artifacts </li> |
| 25 | <li> Self-contained, stand-alone executable that can be run in |
| 26 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 27 | <li> Simple, well-defined, |
| 28 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 29 | </ol> |
| 30 | </blockquote> |
| 31 | |
| 32 | <b>Why should I use this rather than Trac?</b> |
| 33 | |
| 34 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -24,10 +24,11 @@ | |
| 24 | <li> Immutable artifacts </li> |
| 25 | <li> Self-contained, stand-alone executable that can be run in |
| 26 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 27 | <li> Simple, well-defined, |
| 28 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 29 | <li> Integrated <a href="webui.wiki">web interface</a> </li> |
| 30 | </ol> |
| 31 | </blockquote> |
| 32 | |
| 33 | <b>Why should I use this rather than Trac?</b> |
| 34 | |
| 35 |
+1
-1
| --- www/webui.wiki | ||
| +++ www/webui.wiki | ||
| @@ -45,11 +45,11 @@ | ||
| 45 | 45 | from within an open check-out, you can omit the repository name: |
| 46 | 46 | |
| 47 | 47 | <b>fossil ui</b> |
| 48 | 48 | |
| 49 | 49 | The latter case is a very useful short-cut when you are working on a |
| 50 | -fossil project and what to quickly do some work with the interface. | |
| 50 | +fossil project and you what to quickly do some work with the web interface. | |
| 51 | 51 | Notice that fossil automatically finds an unused TCP port to run the |
| 52 | 52 | server own and automatically points your web browser to the correct |
| 53 | 53 | URL. So there is never any fumbling around trying to find an open |
| 54 | 54 | port or to type arcane strings into your browser URL entry box. |
| 55 | 55 | The interface just pops right up, ready to run. |
| 56 | 56 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -45,11 +45,11 @@ | |
| 45 | from within an open check-out, you can omit the repository name: |
| 46 | |
| 47 | <b>fossil ui</b> |
| 48 | |
| 49 | The latter case is a very useful short-cut when you are working on a |
| 50 | fossil project and what to quickly do some work with the interface. |
| 51 | Notice that fossil automatically finds an unused TCP port to run the |
| 52 | server own and automatically points your web browser to the correct |
| 53 | URL. So there is never any fumbling around trying to find an open |
| 54 | port or to type arcane strings into your browser URL entry box. |
| 55 | The interface just pops right up, ready to run. |
| 56 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -45,11 +45,11 @@ | |
| 45 | from within an open check-out, you can omit the repository name: |
| 46 | |
| 47 | <b>fossil ui</b> |
| 48 | |
| 49 | The latter case is a very useful short-cut when you are working on a |
| 50 | fossil project and you what to quickly do some work with the web interface. |
| 51 | Notice that fossil automatically finds an unused TCP port to run the |
| 52 | server own and automatically points your web browser to the correct |
| 53 | URL. So there is never any fumbling around trying to find an open |
| 54 | port or to type arcane strings into your browser URL entry box. |
| 55 | The interface just pops right up, ready to run. |
| 56 |
+5
-3
| --- www/wikitheory.wiki | ||
| +++ www/wikitheory.wiki | ||
| @@ -27,11 +27,11 @@ | ||
| 27 | 27 | all formatting tasks. |
| 28 | 28 | |
| 29 | 29 | 3. Where the fossil wiki markup language is insufficient, HTML is |
| 30 | 30 | used. HTML is a standard language familiar to most programmers so |
| 31 | 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. | |
| 32 | + does not need to be used very often so is not a burden. | |
| 33 | 33 | |
| 34 | 34 | |
| 35 | 35 | <h2>Stand-alone Wiki Pages</h2> |
| 36 | 36 | |
| 37 | 37 | Each wiki page has its own revision history which is independent of |
| @@ -40,11 +40,11 @@ | ||
| 40 | 40 | no mechanism in the user interface to support branching and merging. |
| 41 | 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | 42 | page that has the most recent timestamp. |
| 43 | 43 | |
| 44 | 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 | -page on separate repositories, then those repositories are synced, | |
| 45 | +page on separate repositories and those repositories are synced, | |
| 46 | 46 | the wiki page will fork. The web interface will display whichever edit |
| 47 | 47 | was checked in last. The other edit can be found in the history. The |
| 48 | 48 | file format will support merging the branches back together, but there |
| 49 | 49 | is no mechanism in the user interface (yet) to perform the merge. |
| 50 | 50 | |
| @@ -63,13 +63,15 @@ | ||
| 63 | 63 | wrong with that. But other projects prefer to keep documentation as part |
| 64 | 64 | of the source tree, so that it is versioned along with the source tree and |
| 65 | 65 | so that only developers with check-in privileges can change it. |
| 66 | 66 | Embedded documentation serves this latter purpose. Both forms of documentation |
| 67 | 67 | use the exact same wiki markup language. Some projects may choose to |
| 68 | -use both forms of documentation at the same time. | |
| 68 | +use both forms of documentation at the same time. Because the same | |
| 69 | +format is used, it is trival to move file from wiki to embedded documentation | |
| 70 | +or back again as the project evolves. | |
| 69 | 71 | |
| 70 | 72 | <h2>Bug-reports and check-in comments</h2> |
| 71 | 73 | |
| 72 | 74 | The comments on check-ins and the text in the descriptions of bug reports |
| 73 | 75 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 74 | 76 | There is never a need to learn one formatting language for documentation |
| 75 | 77 | and a different markup for bugs or for check-in comments. |
| 76 | 78 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -27,11 +27,11 @@ | |
| 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 |
| @@ -40,11 +40,11 @@ | |
| 40 | no mechanism in the user interface to support branching and merging. |
| 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | page that has the most recent timestamp. |
| 43 | |
| 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 | page on separate repositories, then those repositories are synced, |
| 46 | the wiki page will fork. The web interface will display whichever edit |
| 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 | |
| @@ -63,13 +63,15 @@ | |
| 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 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -27,11 +27,11 @@ | |
| 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 is not 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 |
| @@ -40,11 +40,11 @@ | |
| 40 | no mechanism in the user interface to support branching and merging. |
| 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | page that has the most recent timestamp. |
| 43 | |
| 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 | page on separate repositories and those repositories are synced, |
| 46 | the wiki page will fork. The web interface will display whichever edit |
| 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 | |
| @@ -63,13 +63,15 @@ | |
| 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. Because the same |
| 69 | format is used, it is trival to move file from wiki to embedded documentation |
| 70 | or back again as the project evolves. |
| 71 | |
| 72 | <h2>Bug-reports and check-in comments</h2> |
| 73 | |
| 74 | The comments on check-ins and the text in the descriptions of bug reports |
| 75 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 76 | There is never a need to learn one formatting language for documentation |
| 77 | and a different markup for bugs or for check-in comments. |
| 78 |