Fossil SCM
Make "fossil fusefs" entry in changelog a hyperlink. Use a "T" in stead of "+" in hyperlinks containing dates, in order to prevent ambiugity. A few typos in wiki.
Commit
68ce1305b106050d70b8fcac554125f368a5ab5a
Parent
7ba8311e5748985…
5 files changed
+4
-4
+4
-3
+15
-15
+8
-8
+7
-7
+4
-4
| --- test/graph-test-1.wiki | ||
| +++ test/graph-test-1.wiki | ||
| @@ -1,9 +1,9 @@ | ||
| 1 | 1 | <title>Graph Test One</title> |
| 2 | 2 | |
| 3 | 3 | This page contains examples a list of URLs of timelines with |
| 4 | -interesting graphs. Click on all URLs, one by one, to verify | |
| 4 | +interesting graphs. Click on all URLs, one by one, to verify | |
| 5 | 5 | the correct operation of the graph drawing logic. |
| 6 | 6 | |
| 7 | 7 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08" target="testwindow"> |
| 8 | 8 | 20-element timeline, check-ins only, before 2010-11-08</a> |
| 9 | 9 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08&ng" target="testwindow"> |
| @@ -12,13 +12,13 @@ | ||
| 12 | 12 | 20-element timeline, check-ins only, file changes, before 2010-11-08</a> |
| 13 | 13 | * <a href="../../../timeline?n=40&y=ci&b=2010-11-08" target="testwindow"> |
| 14 | 14 | 40-element timeline, check-ins only, before 2010-11-08</a> |
| 15 | 15 | * <a href="../../../timeline?n=1000&y=ci&b=2010-11-08" target="testwindow"> |
| 16 | 16 | 1000-element timeline, check-ins only, before 2010-11-08</a> |
| 17 | - * <a href="../../../timeline?n=10&c=2010-11-07+10:23:00" target="testwindow"> | |
| 17 | + * <a href="../../../timeline?n=10&c=2010-11-07T10:23:00" target="testwindow"> | |
| 18 | 18 | 10-elements circa 2010-11-07 10:23:00, with dividers</a> |
| 19 | - * <a href="../../../timeline?n=10&c=2010-11-07+10:23:00&nd" | |
| 19 | + * <a href="../../../timeline?n=10&c=2010-11-07T10:23:00&nd" | |
| 20 | 20 | target="testwindow"> |
| 21 | 21 | 10-elements circa 2010-11-07 10:23:00, without dividers</a> |
| 22 | 22 | * <a href="../../../timeline?f=3ea66260b5555" target="testwindow"> |
| 23 | 23 | Parents and children of check-in 3ea66260b5555</a> |
| 24 | 24 | * <a href="../../../timeline?d=e5fe4164f74a7576&p=e5fe4164f74a7576&n=3" |
| @@ -49,11 +49,11 @@ | ||
| 49 | 49 | * <a href="../../../timeline?a=1970-01-01" target="testwindow"> |
| 50 | 50 | 20 elements after 1970-01-01.</a> |
| 51 | 51 | * <a href="../../../timeline?n=100000000&y=ci" target="testwindow"> |
| 52 | 52 | All check-ins - a huge graph.</a> |
| 53 | 53 | * <a href="../../../timeline?f=8dfed953f7530442" target="testwindow"> |
| 54 | - This malformed commit has a | |
| 54 | + This malformed commit has a | |
| 55 | 55 | merge parent which is not a valid checkin.</a> |
| 56 | 56 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9" |
| 57 | 57 | target="testwindow"> |
| 58 | 58 | From e663bac6f7 to a298a0e2f9 by shortest path.</a> |
| 59 | 59 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9&nomerge" |
| 60 | 60 |
| --- test/graph-test-1.wiki | |
| +++ test/graph-test-1.wiki | |
| @@ -1,9 +1,9 @@ | |
| 1 | <title>Graph Test One</title> |
| 2 | |
| 3 | This page contains examples a list of URLs of timelines with |
| 4 | interesting graphs. Click on all URLs, one by one, to verify |
| 5 | the correct operation of the graph drawing logic. |
| 6 | |
| 7 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08" target="testwindow"> |
| 8 | 20-element timeline, check-ins only, before 2010-11-08</a> |
| 9 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08&ng" target="testwindow"> |
| @@ -12,13 +12,13 @@ | |
| 12 | 20-element timeline, check-ins only, file changes, before 2010-11-08</a> |
| 13 | * <a href="../../../timeline?n=40&y=ci&b=2010-11-08" target="testwindow"> |
| 14 | 40-element timeline, check-ins only, before 2010-11-08</a> |
| 15 | * <a href="../../../timeline?n=1000&y=ci&b=2010-11-08" target="testwindow"> |
| 16 | 1000-element timeline, check-ins only, before 2010-11-08</a> |
| 17 | * <a href="../../../timeline?n=10&c=2010-11-07+10:23:00" target="testwindow"> |
| 18 | 10-elements circa 2010-11-07 10:23:00, with dividers</a> |
| 19 | * <a href="../../../timeline?n=10&c=2010-11-07+10:23:00&nd" |
| 20 | target="testwindow"> |
| 21 | 10-elements circa 2010-11-07 10:23:00, without dividers</a> |
| 22 | * <a href="../../../timeline?f=3ea66260b5555" target="testwindow"> |
| 23 | Parents and children of check-in 3ea66260b5555</a> |
| 24 | * <a href="../../../timeline?d=e5fe4164f74a7576&p=e5fe4164f74a7576&n=3" |
| @@ -49,11 +49,11 @@ | |
| 49 | * <a href="../../../timeline?a=1970-01-01" target="testwindow"> |
| 50 | 20 elements after 1970-01-01.</a> |
| 51 | * <a href="../../../timeline?n=100000000&y=ci" target="testwindow"> |
| 52 | All check-ins - a huge graph.</a> |
| 53 | * <a href="../../../timeline?f=8dfed953f7530442" target="testwindow"> |
| 54 | This malformed commit has a |
| 55 | merge parent which is not a valid checkin.</a> |
| 56 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9" |
| 57 | target="testwindow"> |
| 58 | From e663bac6f7 to a298a0e2f9 by shortest path.</a> |
| 59 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9&nomerge" |
| 60 |
| --- test/graph-test-1.wiki | |
| +++ test/graph-test-1.wiki | |
| @@ -1,9 +1,9 @@ | |
| 1 | <title>Graph Test One</title> |
| 2 | |
| 3 | This page contains examples a list of URLs of timelines with |
| 4 | interesting graphs. Click on all URLs, one by one, to verify |
| 5 | the correct operation of the graph drawing logic. |
| 6 | |
| 7 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08" target="testwindow"> |
| 8 | 20-element timeline, check-ins only, before 2010-11-08</a> |
| 9 | * <a href="../../../timeline?n=20&y=ci&b=2010-11-08&ng" target="testwindow"> |
| @@ -12,13 +12,13 @@ | |
| 12 | 20-element timeline, check-ins only, file changes, before 2010-11-08</a> |
| 13 | * <a href="../../../timeline?n=40&y=ci&b=2010-11-08" target="testwindow"> |
| 14 | 40-element timeline, check-ins only, before 2010-11-08</a> |
| 15 | * <a href="../../../timeline?n=1000&y=ci&b=2010-11-08" target="testwindow"> |
| 16 | 1000-element timeline, check-ins only, before 2010-11-08</a> |
| 17 | * <a href="../../../timeline?n=10&c=2010-11-07T10:23:00" target="testwindow"> |
| 18 | 10-elements circa 2010-11-07 10:23:00, with dividers</a> |
| 19 | * <a href="../../../timeline?n=10&c=2010-11-07T10:23:00&nd" |
| 20 | target="testwindow"> |
| 21 | 10-elements circa 2010-11-07 10:23:00, without dividers</a> |
| 22 | * <a href="../../../timeline?f=3ea66260b5555" target="testwindow"> |
| 23 | Parents and children of check-in 3ea66260b5555</a> |
| 24 | * <a href="../../../timeline?d=e5fe4164f74a7576&p=e5fe4164f74a7576&n=3" |
| @@ -49,11 +49,11 @@ | |
| 49 | * <a href="../../../timeline?a=1970-01-01" target="testwindow"> |
| 50 | 20 elements after 1970-01-01.</a> |
| 51 | * <a href="../../../timeline?n=100000000&y=ci" target="testwindow"> |
| 52 | All check-ins - a huge graph.</a> |
| 53 | * <a href="../../../timeline?f=8dfed953f7530442" target="testwindow"> |
| 54 | This malformed commit has a |
| 55 | merge parent which is not a valid checkin.</a> |
| 56 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9" |
| 57 | target="testwindow"> |
| 58 | From e663bac6f7 to a298a0e2f9 by shortest path.</a> |
| 59 | * <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9&nomerge" |
| 60 |
+4
-3
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -1,13 +1,14 @@ | ||
| 1 | 1 | <title>Change Log</title> |
| 2 | 2 | |
| 3 | 3 | <h2>Changes For Version 1.30 (as yet unreleased)</h2> |
| 4 | 4 | * Add setting to control the number of times autosync will be tried before |
| 5 | 5 | returning an error. |
| 6 | - * Add the "fossil fusefs DIRECTORY" command that mounts a Fuse Filesystem | |
| 7 | - at the given DIRECTORY and populates it with read-only copies of all | |
| 8 | - historical check-ins. This only works on systems that support FuseFS. | |
| 6 | + * Add the [/help/fusefs|fossil fusefs DIRECTORY] command that mounts a | |
| 7 | + Fuse Filesystem at the given DIRECTORY and populates it with read-only | |
| 8 | + copies of all historical check-ins. This only works on systems that | |
| 9 | + support FuseFS. | |
| 9 | 10 | * Support customization of commands and webpages, including the ability to |
| 10 | 11 | add new ones, via the "TH1 hooks" feature. Disabled by default. Enabled |
| 11 | 12 | via a compile-time option. |
| 12 | 13 | * Add the <nowiki>[checkout], [render], [styleHeader], [styleFooter], |
| 13 | 14 | [trace], [getParameter], [setParameter], and [artifact]</nowiki> commands |
| 14 | 15 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -1,13 +1,14 @@ | |
| 1 | <title>Change Log</title> |
| 2 | |
| 3 | <h2>Changes For Version 1.30 (as yet unreleased)</h2> |
| 4 | * Add setting to control the number of times autosync will be tried before |
| 5 | returning an error. |
| 6 | * Add the "fossil fusefs DIRECTORY" command that mounts a Fuse Filesystem |
| 7 | at the given DIRECTORY and populates it with read-only copies of all |
| 8 | historical check-ins. This only works on systems that support FuseFS. |
| 9 | * Support customization of commands and webpages, including the ability to |
| 10 | add new ones, via the "TH1 hooks" feature. Disabled by default. Enabled |
| 11 | via a compile-time option. |
| 12 | * Add the <nowiki>[checkout], [render], [styleHeader], [styleFooter], |
| 13 | [trace], [getParameter], [setParameter], and [artifact]</nowiki> commands |
| 14 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -1,13 +1,14 @@ | |
| 1 | <title>Change Log</title> |
| 2 | |
| 3 | <h2>Changes For Version 1.30 (as yet unreleased)</h2> |
| 4 | * Add setting to control the number of times autosync will be tried before |
| 5 | returning an error. |
| 6 | * Add the [/help/fusefs|fossil fusefs DIRECTORY] command that mounts a |
| 7 | Fuse Filesystem at the given DIRECTORY and populates it with read-only |
| 8 | copies of all historical check-ins. This only works on systems that |
| 9 | support FuseFS. |
| 10 | * Support customization of commands and webpages, including the ability to |
| 11 | add new ones, via the "TH1 hooks" feature. Disabled by default. Enabled |
| 12 | via a compile-time option. |
| 13 | * Add the <nowiki>[checkout], [render], [styleHeader], [styleFooter], |
| 14 | [trace], [getParameter], [setParameter], and [artifact]</nowiki> commands |
| 15 |
+15
-15
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -3,15 +3,15 @@ | ||
| 3 | 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | 4 | |
| 5 | 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | 6 | it is [./inout.wiki | easy to change]. |
| 7 | 7 | |
| 8 | -But it also helps to be informed about the differences between | |
| 8 | +But it also helps to be informed about the differences between | |
| 9 | 9 | [http://git-scm.com | Git] and Fossil. See the table below for |
| 10 | 10 | a high-level summary and the text that follows for more details. |
| 11 | 11 | |
| 12 | -Keep in mind that you are reading this on a Fossil website, | |
| 12 | +Keep in mind that you are reading this on a Fossil website, | |
| 13 | 13 | so the information here |
| 14 | 14 | might be biased in favor of Fossil. Ask around with people who have |
| 15 | 15 | used both Fossil and Git for other opinions. |
| 16 | 16 | |
| 17 | 17 | <h2>2.0 Executive Summary:</h2> |
| @@ -47,21 +47,21 @@ | ||
| 47 | 47 | <h3>3.2 Sharding versus Replicating</h3> |
| 48 | 48 | |
| 49 | 49 | Git makes it easy for each repository in a project to hold a subset of |
| 50 | 50 | the branches for that project. In fact, it is entirely possible and not |
| 51 | 51 | uncommon for no repository in the project to hold all the different code |
| 52 | -versions for a project. Instead the information is distributed. | |
| 52 | +versions for a project. Instead the information is distributed. | |
| 53 | 53 | Individual developers have one or more private branches. A hierarchy |
| 54 | 54 | of integrators merge changes from individual developers into collaborative |
| 55 | 55 | branches, until all the changes are merged together at the top-level master |
| 56 | 56 | branch. And all of this can be accomplished without having to have all the |
| 57 | 57 | code in any one repository. Developers or groups of developers can share |
| 58 | 58 | only those branches that they want to share and keep other branchs of the |
| 59 | 59 | project private. This is analogous to sharding an a distributed database. |
| 60 | 60 | |
| 61 | 61 | Fossil allows private branches, but its default mode is to share everything. |
| 62 | -And so in a Fossil project, all respositories tend to contain all of the | |
| 62 | +And so in a Fossil project, all repositories tend to contain all of the | |
| 63 | 63 | content at all times. This is analogous to replication in a |
| 64 | 64 | distributed database. |
| 65 | 65 | |
| 66 | 66 | The Git model works best for large projects, like the |
| 67 | 67 | Linux kernel for which Git was designed. |
| @@ -73,35 +73,35 @@ | ||
| 73 | 73 | works in his or her own branch and then merges changes up the hierarchy |
| 74 | 74 | until they reach the master branch. |
| 75 | 75 | |
| 76 | 76 | Fossil is designed for smaller and non-hierarchical teams where all |
| 77 | 77 | developers are operating directly on the master branch, or at most |
| 78 | -a small number of well defined branches. | |
| 78 | +a small number of well defined branches. | |
| 79 | 79 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | 80 | for multiple developers to work on a single branch and maintain |
| 81 | 81 | linear development on that branch and avoid needless forking |
| 82 | 82 | and merging. |
| 83 | 83 | |
| 84 | 84 | <h3>3.3 Branches</h3> |
| 85 | 85 | |
| 86 | -Git (and especially GitHub) encourages a workflow where each developer | |
| 86 | +Git (and especially GitHub) encourages a workflow where each developer | |
| 87 | 87 | has his or her own branch or branches. Developers then send "pull requests" |
| 88 | 88 | to have their changes be merged into "official" branches by integrators. |
| 89 | 89 | For example, the Linux kernel team has a hierarchy of integrators with |
| 90 | 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | 91 | private branches of the source tree into which they make their own changes. |
| 92 | 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | -changes merge up the hierarchy until (hopefully) they are pulled into | |
| 95 | +changes merge up the hierarchy until (hopefully) they are pulled into | |
| 96 | 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | 97 | |
| 98 | 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | 100 | in control of the branch. Branches are developer-centric. |
| 101 | 101 | |
| 102 | -Fossil, on the other hand, encourages a workflow where branches are | |
| 102 | +Fossil, on the other hand, encourages a workflow where branches are | |
| 103 | 103 | associated with features or releases, not individual developers. |
| 104 | 104 | All developers share all branches in common, and two |
| 105 | 105 | or more developers can and often do intersperse commits onto the same branch. |
| 106 | 106 | Branches do not belong to individuals. All branches are read/write |
| 107 | 107 | accessible to all developers at all times. There is no need |
| @@ -113,11 +113,11 @@ | ||
| 113 | 113 | branches in Fossil are feature-centric. |
| 114 | 114 | |
| 115 | 115 | The Git approach scales much better for large projects like the Linux |
| 116 | 116 | kernel with thousands of contributors who in many cases don't even know |
| 117 | 117 | each others names. The integrators serve a gatekeeper role to help keep |
| 118 | -undesirable code out of the official Linux source tree. On the other hand, | |
| 118 | +undesirable code out of the official Linux source tree. On the other hand, | |
| 119 | 119 | not many projects are as big or as loosely organized as the Linux kernel. |
| 120 | 120 | Most projects have a small team of developers who all know each other |
| 121 | 121 | well and trust each other, and who enjoy working together collaboratively |
| 122 | 122 | without the overhead and hierarchy of integrators. |
| 123 | 123 | |
| @@ -141,14 +141,14 @@ | ||
| 141 | 141 | to think about version control to some extent. But one wants to minimize |
| 142 | 142 | the thinking about version control. |
| 143 | 143 | |
| 144 | 144 | Git requires the developer to maintain a more complex mental model than |
| 145 | 145 | most other DVCSes. Git takes longer to learn. And you have to spend |
| 146 | -more time thinking about what you are doing with Git. | |
| 146 | +more time thinking about what you are doing with Git. | |
| 147 | 147 | |
| 148 | 148 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 149 | -require little thinking about how to operating it. | |
| 149 | +require little thinking about how to operating it. | |
| 150 | 150 | [./quotes.wiki | Reports from the field] |
| 151 | 151 | indicate that Fossil is mostly successful at this effort. |
| 152 | 152 | |
| 153 | 153 | <h3>3.5 Web Interface</h3> |
| 154 | 154 | |
| @@ -195,17 +195,17 @@ | ||
| 195 | 195 | |
| 196 | 196 | Git features the "rebase" command which can be used to change the |
| 197 | 197 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 198 | 198 | a complex sequence of check-ins to make their intent easier for others |
| 199 | 199 | to understand. This is important if you view the history of a project |
| 200 | -as part of the documentation for the project. | |
| 200 | +as part of the documentation for the project. | |
| 201 | 201 | |
| 202 | 202 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 203 | 203 | stubornly refuses to change it. |
| 204 | 204 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 205 | 205 | can be revised, and check-ins can be moved onto new branches even after |
| 206 | -the check-in has occurred) but the correction is an addition to the respository | |
| 206 | +the check-in has occurred) but the correction is an addition to the repository | |
| 207 | 207 | and the original actions are preserved and displayed alongside |
| 208 | 208 | the corrections, thus preserving an historically accurate audit trail. |
| 209 | 209 | This is analogous to an accountant marking through an incorrect |
| 210 | 210 | entry in a ledger and writing in a correction beside it, rather than |
| 211 | 211 | erasing and incorrect entry. |
| @@ -216,12 +216,12 @@ | ||
| 216 | 216 | The lack of a "rebase" command and the inability to rewrite history |
| 217 | 217 | is considered a feature of Fossil, not an omission or bug. |
| 218 | 218 | |
| 219 | 219 | <h3>3.9 License</h3> |
| 220 | 220 | |
| 221 | -Both Git and Fossil are open-source. Git is under | |
| 221 | +Both Git and Fossil are open-source. Git is under | |
| 222 | 222 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 223 | -under the | |
| 223 | +under the | |
| 224 | 224 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 225 | 225 | The difference should not be of a concern to most users. However, |
| 226 | 226 | some corporate lawyers have objections to using GPL products and |
| 227 | 227 | are more comfortable with a BSD-style license. |
| 228 | 228 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -3,15 +3,15 @@ | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | it is [./inout.wiki | easy to change]. |
| 7 | |
| 8 | But it also helps to be informed about the differences between |
| 9 | [http://git-scm.com | Git] and Fossil. See the table below for |
| 10 | a high-level summary and the text that follows for more details. |
| 11 | |
| 12 | Keep in mind that you are reading this on a Fossil website, |
| 13 | so the information here |
| 14 | might be biased in favor of Fossil. Ask around with people who have |
| 15 | used both Fossil and Git for other opinions. |
| 16 | |
| 17 | <h2>2.0 Executive Summary:</h2> |
| @@ -47,21 +47,21 @@ | |
| 47 | <h3>3.2 Sharding versus Replicating</h3> |
| 48 | |
| 49 | Git makes it easy for each repository in a project to hold a subset of |
| 50 | the branches for that project. In fact, it is entirely possible and not |
| 51 | uncommon for no repository in the project to hold all the different code |
| 52 | versions for a project. Instead the information is distributed. |
| 53 | Individual developers have one or more private branches. A hierarchy |
| 54 | of integrators merge changes from individual developers into collaborative |
| 55 | branches, until all the changes are merged together at the top-level master |
| 56 | branch. And all of this can be accomplished without having to have all the |
| 57 | code in any one repository. Developers or groups of developers can share |
| 58 | only those branches that they want to share and keep other branchs of the |
| 59 | project private. This is analogous to sharding an a distributed database. |
| 60 | |
| 61 | Fossil allows private branches, but its default mode is to share everything. |
| 62 | And so in a Fossil project, all respositories tend to contain all of the |
| 63 | content at all times. This is analogous to replication in a |
| 64 | distributed database. |
| 65 | |
| 66 | The Git model works best for large projects, like the |
| 67 | Linux kernel for which Git was designed. |
| @@ -73,35 +73,35 @@ | |
| 73 | works in his or her own branch and then merges changes up the hierarchy |
| 74 | until they reach the master branch. |
| 75 | |
| 76 | Fossil is designed for smaller and non-hierarchical teams where all |
| 77 | developers are operating directly on the master branch, or at most |
| 78 | a small number of well defined branches. |
| 79 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | for multiple developers to work on a single branch and maintain |
| 81 | linear development on that branch and avoid needless forking |
| 82 | and merging. |
| 83 | |
| 84 | <h3>3.3 Branches</h3> |
| 85 | |
| 86 | Git (and especially GitHub) encourages a workflow where each developer |
| 87 | has his or her own branch or branches. Developers then send "pull requests" |
| 88 | to have their changes be merged into "official" branches by integrators. |
| 89 | For example, the Linux kernel team has a hierarchy of integrators with |
| 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | private branches of the source tree into which they make their own changes. |
| 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | changes merge up the hierarchy until (hopefully) they are pulled into |
| 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | |
| 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | in control of the branch. Branches are developer-centric. |
| 101 | |
| 102 | Fossil, on the other hand, encourages a workflow where branches are |
| 103 | associated with features or releases, not individual developers. |
| 104 | All developers share all branches in common, and two |
| 105 | or more developers can and often do intersperse commits onto the same branch. |
| 106 | Branches do not belong to individuals. All branches are read/write |
| 107 | accessible to all developers at all times. There is no need |
| @@ -113,11 +113,11 @@ | |
| 113 | branches in Fossil are feature-centric. |
| 114 | |
| 115 | The Git approach scales much better for large projects like the Linux |
| 116 | kernel with thousands of contributors who in many cases don't even know |
| 117 | each others names. The integrators serve a gatekeeper role to help keep |
| 118 | undesirable code out of the official Linux source tree. On the other hand, |
| 119 | not many projects are as big or as loosely organized as the Linux kernel. |
| 120 | Most projects have a small team of developers who all know each other |
| 121 | well and trust each other, and who enjoy working together collaboratively |
| 122 | without the overhead and hierarchy of integrators. |
| 123 | |
| @@ -141,14 +141,14 @@ | |
| 141 | to think about version control to some extent. But one wants to minimize |
| 142 | the thinking about version control. |
| 143 | |
| 144 | Git requires the developer to maintain a more complex mental model than |
| 145 | most other DVCSes. Git takes longer to learn. And you have to spend |
| 146 | more time thinking about what you are doing with Git. |
| 147 | |
| 148 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 149 | require little thinking about how to operating it. |
| 150 | [./quotes.wiki | Reports from the field] |
| 151 | indicate that Fossil is mostly successful at this effort. |
| 152 | |
| 153 | <h3>3.5 Web Interface</h3> |
| 154 | |
| @@ -195,17 +195,17 @@ | |
| 195 | |
| 196 | Git features the "rebase" command which can be used to change the |
| 197 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 198 | a complex sequence of check-ins to make their intent easier for others |
| 199 | to understand. This is important if you view the history of a project |
| 200 | as part of the documentation for the project. |
| 201 | |
| 202 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 203 | stubornly refuses to change it. |
| 204 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 205 | can be revised, and check-ins can be moved onto new branches even after |
| 206 | the check-in has occurred) but the correction is an addition to the respository |
| 207 | and the original actions are preserved and displayed alongside |
| 208 | the corrections, thus preserving an historically accurate audit trail. |
| 209 | This is analogous to an accountant marking through an incorrect |
| 210 | entry in a ledger and writing in a correction beside it, rather than |
| 211 | erasing and incorrect entry. |
| @@ -216,12 +216,12 @@ | |
| 216 | The lack of a "rebase" command and the inability to rewrite history |
| 217 | is considered a feature of Fossil, not an omission or bug. |
| 218 | |
| 219 | <h3>3.9 License</h3> |
| 220 | |
| 221 | Both Git and Fossil are open-source. Git is under |
| 222 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 223 | under the |
| 224 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 225 | The difference should not be of a concern to most users. However, |
| 226 | some corporate lawyers have objections to using GPL products and |
| 227 | are more comfortable with a BSD-style license. |
| 228 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -3,15 +3,15 @@ | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | it is [./inout.wiki | easy to change]. |
| 7 | |
| 8 | But it also helps to be informed about the differences between |
| 9 | [http://git-scm.com | Git] and Fossil. See the table below for |
| 10 | a high-level summary and the text that follows for more details. |
| 11 | |
| 12 | Keep in mind that you are reading this on a Fossil website, |
| 13 | so the information here |
| 14 | might be biased in favor of Fossil. Ask around with people who have |
| 15 | used both Fossil and Git for other opinions. |
| 16 | |
| 17 | <h2>2.0 Executive Summary:</h2> |
| @@ -47,21 +47,21 @@ | |
| 47 | <h3>3.2 Sharding versus Replicating</h3> |
| 48 | |
| 49 | Git makes it easy for each repository in a project to hold a subset of |
| 50 | the branches for that project. In fact, it is entirely possible and not |
| 51 | uncommon for no repository in the project to hold all the different code |
| 52 | versions for a project. Instead the information is distributed. |
| 53 | Individual developers have one or more private branches. A hierarchy |
| 54 | of integrators merge changes from individual developers into collaborative |
| 55 | branches, until all the changes are merged together at the top-level master |
| 56 | branch. And all of this can be accomplished without having to have all the |
| 57 | code in any one repository. Developers or groups of developers can share |
| 58 | only those branches that they want to share and keep other branchs of the |
| 59 | project private. This is analogous to sharding an a distributed database. |
| 60 | |
| 61 | Fossil allows private branches, but its default mode is to share everything. |
| 62 | And so in a Fossil project, all repositories tend to contain all of the |
| 63 | content at all times. This is analogous to replication in a |
| 64 | distributed database. |
| 65 | |
| 66 | The Git model works best for large projects, like the |
| 67 | Linux kernel for which Git was designed. |
| @@ -73,35 +73,35 @@ | |
| 73 | works in his or her own branch and then merges changes up the hierarchy |
| 74 | until they reach the master branch. |
| 75 | |
| 76 | Fossil is designed for smaller and non-hierarchical teams where all |
| 77 | developers are operating directly on the master branch, or at most |
| 78 | a small number of well defined branches. |
| 79 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | for multiple developers to work on a single branch and maintain |
| 81 | linear development on that branch and avoid needless forking |
| 82 | and merging. |
| 83 | |
| 84 | <h3>3.3 Branches</h3> |
| 85 | |
| 86 | Git (and especially GitHub) encourages a workflow where each developer |
| 87 | has his or her own branch or branches. Developers then send "pull requests" |
| 88 | to have their changes be merged into "official" branches by integrators. |
| 89 | For example, the Linux kernel team has a hierarchy of integrators with |
| 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | private branches of the source tree into which they make their own changes. |
| 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | changes merge up the hierarchy until (hopefully) they are pulled into |
| 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | |
| 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | in control of the branch. Branches are developer-centric. |
| 101 | |
| 102 | Fossil, on the other hand, encourages a workflow where branches are |
| 103 | associated with features or releases, not individual developers. |
| 104 | All developers share all branches in common, and two |
| 105 | or more developers can and often do intersperse commits onto the same branch. |
| 106 | Branches do not belong to individuals. All branches are read/write |
| 107 | accessible to all developers at all times. There is no need |
| @@ -113,11 +113,11 @@ | |
| 113 | branches in Fossil are feature-centric. |
| 114 | |
| 115 | The Git approach scales much better for large projects like the Linux |
| 116 | kernel with thousands of contributors who in many cases don't even know |
| 117 | each others names. The integrators serve a gatekeeper role to help keep |
| 118 | undesirable code out of the official Linux source tree. On the other hand, |
| 119 | not many projects are as big or as loosely organized as the Linux kernel. |
| 120 | Most projects have a small team of developers who all know each other |
| 121 | well and trust each other, and who enjoy working together collaboratively |
| 122 | without the overhead and hierarchy of integrators. |
| 123 | |
| @@ -141,14 +141,14 @@ | |
| 141 | to think about version control to some extent. But one wants to minimize |
| 142 | the thinking about version control. |
| 143 | |
| 144 | Git requires the developer to maintain a more complex mental model than |
| 145 | most other DVCSes. Git takes longer to learn. And you have to spend |
| 146 | more time thinking about what you are doing with Git. |
| 147 | |
| 148 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 149 | require little thinking about how to operating it. |
| 150 | [./quotes.wiki | Reports from the field] |
| 151 | indicate that Fossil is mostly successful at this effort. |
| 152 | |
| 153 | <h3>3.5 Web Interface</h3> |
| 154 | |
| @@ -195,17 +195,17 @@ | |
| 195 | |
| 196 | Git features the "rebase" command which can be used to change the |
| 197 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 198 | a complex sequence of check-ins to make their intent easier for others |
| 199 | to understand. This is important if you view the history of a project |
| 200 | as part of the documentation for the project. |
| 201 | |
| 202 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 203 | stubornly refuses to change it. |
| 204 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 205 | can be revised, and check-ins can be moved onto new branches even after |
| 206 | the check-in has occurred) but the correction is an addition to the repository |
| 207 | and the original actions are preserved and displayed alongside |
| 208 | the corrections, thus preserving an historically accurate audit trail. |
| 209 | This is analogous to an accountant marking through an incorrect |
| 210 | entry in a ledger and writing in a correction beside it, rather than |
| 211 | erasing and incorrect entry. |
| @@ -216,12 +216,12 @@ | |
| 216 | The lack of a "rebase" command and the inability to rewrite history |
| 217 | is considered a feature of Fossil, not an omission or bug. |
| 218 | |
| 219 | <h3>3.9 License</h3> |
| 220 | |
| 221 | Both Git and Fossil are open-source. Git is under |
| 222 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 223 | under the |
| 224 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 225 | The difference should not be of a concern to most users. However, |
| 226 | some corporate lawyers have objections to using GPL products and |
| 227 | are more comfortable with a BSD-style license. |
| 228 |
+8
-8
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -7,12 +7,12 @@ | ||
| 7 | 7 | are not transmitted from one repository to another during a sync. |
| 8 | 8 | Passwords are local configuration information that can (and usually does) |
| 9 | 9 | vary from one repository to the next within the same project. |
| 10 | 10 | |
| 11 | 11 | Passwords are stored in the PW field of the USER table. |
| 12 | -In older versions of Fossil (prior to | |
| 13 | -[/timeline?c=2010-01-10+20:56:30 | 2010-01-11]) the password | |
| 12 | +In older versions of Fossil (prior to | |
| 13 | +[/timeline?c=2010-01-10T20:56:30 | 2010-01-11]) the password | |
| 14 | 14 | is stored as cleartext. In newer versions of Fossil, the password |
| 15 | 15 | can be either cleartext or an SHA1 hash (written as a 40-character |
| 16 | 16 | lower-case hexadecimal number). If the USER.PW field contains |
| 17 | 17 | a 40-character string, that string is assumed to be a SHA1 hash. |
| 18 | 18 | If the size of USER.PW is anything other than 40 characters, then |
| @@ -71,14 +71,14 @@ | ||
| 71 | 71 | hashes the password and compares it against the value stored in USER.PW. |
| 72 | 72 | If they match, the server sets a cookie on the client to record the |
| 73 | 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | -of the USER table on the server. | |
| 76 | +of the USER table on the server. | |
| 77 | 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | 78 | for the cookie, encoded as a julian day number. On all subsequent |
| 79 | -HTTP requests, the cookie value is matched against the USER table to | |
| 79 | +HTTP requests, the cookie value is matched against the USER table to | |
| 80 | 80 | enable access to the repository. |
| 81 | 81 | |
| 82 | 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 | 84 | and take over the connection. A cookie-sniffing attack will only work |
| @@ -103,12 +103,12 @@ | ||
| 103 | 103 | over the wire, but that plan has not yet been set in code. |
| 104 | 104 | |
| 105 | 105 | <h2>Sync Protocol Authentication</h2> |
| 106 | 106 | |
| 107 | 107 | A different authentication mechanism is used when one repository wants |
| 108 | -to sync (or push or pull or clone) another respository. When two | |
| 109 | -respositories are syncing, the one that initiates the transaction is | |
| 108 | +to sync (or push or pull or clone) another repository. When two | |
| 109 | +repositories are syncing, the one that initiates the transaction is | |
| 110 | 110 | the client and the repository that responds is the server. The client |
| 111 | 111 | works by sending HTTP requests to the server with a method of "xfer" |
| 112 | 112 | and a content-type of "application/x-fossil". The content is Zlib-compressed |
| 113 | 113 | text consisting of "cards" of instructions. The first card of this content |
| 114 | 114 | is a "login" card responsible for authentication. The login card contains |
| @@ -137,12 +137,12 @@ | ||
| 137 | 137 | <blockquote><pre> |
| 138 | 138 | http://<font color="blue">login:password</font>@servername.org/path |
| 139 | 139 | </pre></blockquote> |
| 140 | 140 | |
| 141 | 141 | For older clients, the password is used for the shared secret as stated |
| 142 | -in the URL and with no encoding. | |
| 143 | -For newer clients, the shared secret is derived from the password | |
| 142 | +in the URL and with no encoding. | |
| 143 | +For newer clients, the shared secret is derived from the password | |
| 144 | 144 | by transformed the password using the SHA1 hash encoding |
| 145 | 145 | described above. However, if the first character of the password is |
| 146 | 146 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 147 | 147 | is used directly as the share secret without the SHA1 encoding. |
| 148 | 148 | |
| 149 | 149 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -7,12 +7,12 @@ | |
| 7 | are not transmitted from one repository to another during a sync. |
| 8 | Passwords are local configuration information that can (and usually does) |
| 9 | vary from one repository to the next within the same project. |
| 10 | |
| 11 | Passwords are stored in the PW field of the USER table. |
| 12 | In older versions of Fossil (prior to |
| 13 | [/timeline?c=2010-01-10+20:56:30 | 2010-01-11]) the password |
| 14 | is stored as cleartext. In newer versions of Fossil, the password |
| 15 | can be either cleartext or an SHA1 hash (written as a 40-character |
| 16 | lower-case hexadecimal number). If the USER.PW field contains |
| 17 | a 40-character string, that string is assumed to be a SHA1 hash. |
| 18 | If the size of USER.PW is anything other than 40 characters, then |
| @@ -71,14 +71,14 @@ | |
| 71 | hashes the password and compares it against the value stored in USER.PW. |
| 72 | If they match, the server sets a cookie on the client to record the |
| 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | of the USER table on the server. |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 | and take over the connection. A cookie-sniffing attack will only work |
| @@ -103,12 +103,12 @@ | |
| 103 | over the wire, but that plan has not yet been set in code. |
| 104 | |
| 105 | <h2>Sync Protocol Authentication</h2> |
| 106 | |
| 107 | A different authentication mechanism is used when one repository wants |
| 108 | to sync (or push or pull or clone) another respository. When two |
| 109 | respositories are syncing, the one that initiates the transaction is |
| 110 | the client and the repository that responds is the server. The client |
| 111 | works by sending HTTP requests to the server with a method of "xfer" |
| 112 | and a content-type of "application/x-fossil". The content is Zlib-compressed |
| 113 | text consisting of "cards" of instructions. The first card of this content |
| 114 | is a "login" card responsible for authentication. The login card contains |
| @@ -137,12 +137,12 @@ | |
| 137 | <blockquote><pre> |
| 138 | http://<font color="blue">login:password</font>@servername.org/path |
| 139 | </pre></blockquote> |
| 140 | |
| 141 | For older clients, the password is used for the shared secret as stated |
| 142 | in the URL and with no encoding. |
| 143 | For newer clients, the shared secret is derived from the password |
| 144 | by transformed the password using the SHA1 hash encoding |
| 145 | described above. However, if the first character of the password is |
| 146 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 147 | is used directly as the share secret without the SHA1 encoding. |
| 148 | |
| 149 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -7,12 +7,12 @@ | |
| 7 | are not transmitted from one repository to another during a sync. |
| 8 | Passwords are local configuration information that can (and usually does) |
| 9 | vary from one repository to the next within the same project. |
| 10 | |
| 11 | Passwords are stored in the PW field of the USER table. |
| 12 | In older versions of Fossil (prior to |
| 13 | [/timeline?c=2010-01-10T20:56:30 | 2010-01-11]) the password |
| 14 | is stored as cleartext. In newer versions of Fossil, the password |
| 15 | can be either cleartext or an SHA1 hash (written as a 40-character |
| 16 | lower-case hexadecimal number). If the USER.PW field contains |
| 17 | a 40-character string, that string is assumed to be a SHA1 hash. |
| 18 | If the size of USER.PW is anything other than 40 characters, then |
| @@ -71,14 +71,14 @@ | |
| 71 | hashes the password and compares it against the value stored in USER.PW. |
| 72 | If they match, the server sets a cookie on the client to record the |
| 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | of the USER table on the server. |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 | and take over the connection. A cookie-sniffing attack will only work |
| @@ -103,12 +103,12 @@ | |
| 103 | over the wire, but that plan has not yet been set in code. |
| 104 | |
| 105 | <h2>Sync Protocol Authentication</h2> |
| 106 | |
| 107 | A different authentication mechanism is used when one repository wants |
| 108 | to sync (or push or pull or clone) another repository. When two |
| 109 | repositories are syncing, the one that initiates the transaction is |
| 110 | the client and the repository that responds is the server. The client |
| 111 | works by sending HTTP requests to the server with a method of "xfer" |
| 112 | and a content-type of "application/x-fossil". The content is Zlib-compressed |
| 113 | text consisting of "cards" of instructions. The first card of this content |
| 114 | is a "login" card responsible for authentication. The login card contains |
| @@ -137,12 +137,12 @@ | |
| 137 | <blockquote><pre> |
| 138 | http://<font color="blue">login:password</font>@servername.org/path |
| 139 | </pre></blockquote> |
| 140 | |
| 141 | For older clients, the password is used for the shared secret as stated |
| 142 | in the URL and with no encoding. |
| 143 | For newer clients, the shared secret is derived from the password |
| 144 | by transformed the password using the SHA1 hash encoding |
| 145 | described above. However, if the first character of the password is |
| 146 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 147 | is used directly as the share secret without the SHA1 encoding. |
| 148 | |
| 149 |
+7
-7
| --- www/tickets.wiki | ||
| +++ www/tickets.wiki | ||
| @@ -101,20 +101,20 @@ | ||
| 101 | 101 | used to uniquely identify the ticket to which the row belongs. These |
| 102 | 102 | keys are for internal use only and may change when doing a "fossil rebuild". |
| 103 | 103 | |
| 104 | 104 | The <b>tkt_uuid</b> field is the unique hexadecimal identifier for the ticket. |
| 105 | 105 | Ticket identifiers appear to be SHA1 hash strings, but they |
| 106 | -are not really the hash of any identifible artifact. They are | |
| 106 | +are not really the hash of any identifiable artifact. They are | |
| 107 | 107 | just random hexadecimal numbers. When creating a new ticket, Fossil uses |
| 108 | -a (high-quality) pseudo-random number generator to create the ticket | |
| 108 | +a (high-quality) pseudo-random number generator to create the ticket | |
| 109 | 109 | number. The ticket numbers are large so that the chance of collision |
| 110 | 110 | between any two tickets is vanishingly small. |
| 111 | 111 | |
| 112 | 112 | The <b>tkt_mtime</b> field of TICKET shows the time (as a Julian day number) |
| 113 | 113 | of the most recent ticket change artifact for that ticket. The |
| 114 | 114 | <b>tkt_mtime</b> field of TICKETCHNG shows the timestamp on the ticket |
| 115 | -change artifact that the TICKETCHNG row refers to. The | |
| 115 | +change artifact that the TICKETCHNG row refers to. The | |
| 116 | 116 | <b>tkt_ctime</b> field of TICKET is the time of the oldest ticket change |
| 117 | 117 | artifact for that ticket, thus holding the time that the ticket was |
| 118 | 118 | created. |
| 119 | 119 | |
| 120 | 120 | The <b>tkt_rid</b> field of TICKETCHNG is the integer primary key in the |
| @@ -160,11 +160,11 @@ | ||
| 160 | 160 | visited, its key/value pairs are examined. For any key/value pair in |
| 161 | 161 | which the key is the same as a field in the TICKET table, the value |
| 162 | 162 | of that pair either replaces or is appended to the previous value |
| 163 | 163 | of the corresponding field in the TICKET table. Whether a value is |
| 164 | 164 | replaced or appended is determined by markings in the ticket change |
| 165 | -artifact itself. Most fields are usually replaced. (For example, to change | |
| 165 | +artifact itself. Most fields are usually replaced. (For example, to change | |
| 166 | 166 | the status from "Open" to "Fixed" would involve a key value pair |
| 167 | 167 | "status/Fixed" with the replace attribute set). The main exception |
| 168 | 168 | is the "comment" field, which is usually appended with new comment |
| 169 | 169 | text. |
| 170 | 170 | |
| @@ -174,26 +174,26 @@ | ||
| 174 | 174 | difference there. |
| 175 | 175 | |
| 176 | 176 | <h3>2.3 Old-Style versus New-Style Tickets</h3> |
| 177 | 177 | |
| 178 | 178 | Older versions of Fossil |
| 179 | -(before [/timeline?c=2012-11-27+16:26:29 | 2012-11-27]) | |
| 179 | +(before [/timeline?c=2012-11-27T16:26:29 | 2012-11-27]) | |
| 180 | 180 | only supported the TICKET table. |
| 181 | 181 | In this older style, new comments were added to tickets by using |
| 182 | 182 | the append-value feature on the comment field. Thus the TICKET.COMMENT |
| 183 | 183 | field contains the complete text of all user comments already appended |
| 184 | 184 | together and ready for display. |
| 185 | 185 | |
| 186 | 186 | A problem with the old approach is that all comment text had to |
| 187 | 187 | be in the same format. In other words, the all comment text had to be |
| 188 | 188 | either plaintext or wiki or HTML. It was not possible for some comments |
| 189 | -to be in HTML and others to be plaintext. Some site adminstrators wanted the | |
| 190 | -ability to mix plaintext, wiki, and HTML comments and display each | |
| 189 | +to be in HTML and others to be plaintext. Some site administrators wanted the | |
| 190 | +ability to mix plaintext, wiki, and HTML comments and display each | |
| 191 | 191 | comment according to its chosen format. Hence, Fossil was enhanced to |
| 192 | 192 | support the "new-style" tickets. |
| 193 | 193 | |
| 194 | 194 | The TICKETCHNG table was added to support new-style tickets. In the new |
| 195 | 195 | style, comment text is stored with the "icomment" (for "Incremental Comment") |
| 196 | 196 | key and appears separately, and with its on mimetype, in multiple rows |
| 197 | 197 | of the TICKETCHNG table. It then falls to the TH1 script code on the |
| 198 | 198 | View Ticket Page to query the TICKETCHNG table and extract and format |
| 199 | 199 | the various comments in timestamp order. |
| 200 | 200 |
| --- www/tickets.wiki | |
| +++ www/tickets.wiki | |
| @@ -101,20 +101,20 @@ | |
| 101 | used to uniquely identify the ticket to which the row belongs. These |
| 102 | keys are for internal use only and may change when doing a "fossil rebuild". |
| 103 | |
| 104 | The <b>tkt_uuid</b> field is the unique hexadecimal identifier for the ticket. |
| 105 | Ticket identifiers appear to be SHA1 hash strings, but they |
| 106 | are not really the hash of any identifible artifact. They are |
| 107 | just random hexadecimal numbers. When creating a new ticket, Fossil uses |
| 108 | a (high-quality) pseudo-random number generator to create the ticket |
| 109 | number. The ticket numbers are large so that the chance of collision |
| 110 | between any two tickets is vanishingly small. |
| 111 | |
| 112 | The <b>tkt_mtime</b> field of TICKET shows the time (as a Julian day number) |
| 113 | of the most recent ticket change artifact for that ticket. The |
| 114 | <b>tkt_mtime</b> field of TICKETCHNG shows the timestamp on the ticket |
| 115 | change artifact that the TICKETCHNG row refers to. The |
| 116 | <b>tkt_ctime</b> field of TICKET is the time of the oldest ticket change |
| 117 | artifact for that ticket, thus holding the time that the ticket was |
| 118 | created. |
| 119 | |
| 120 | The <b>tkt_rid</b> field of TICKETCHNG is the integer primary key in the |
| @@ -160,11 +160,11 @@ | |
| 160 | visited, its key/value pairs are examined. For any key/value pair in |
| 161 | which the key is the same as a field in the TICKET table, the value |
| 162 | of that pair either replaces or is appended to the previous value |
| 163 | of the corresponding field in the TICKET table. Whether a value is |
| 164 | replaced or appended is determined by markings in the ticket change |
| 165 | artifact itself. Most fields are usually replaced. (For example, to change |
| 166 | the status from "Open" to "Fixed" would involve a key value pair |
| 167 | "status/Fixed" with the replace attribute set). The main exception |
| 168 | is the "comment" field, which is usually appended with new comment |
| 169 | text. |
| 170 | |
| @@ -174,26 +174,26 @@ | |
| 174 | difference there. |
| 175 | |
| 176 | <h3>2.3 Old-Style versus New-Style Tickets</h3> |
| 177 | |
| 178 | Older versions of Fossil |
| 179 | (before [/timeline?c=2012-11-27+16:26:29 | 2012-11-27]) |
| 180 | only supported the TICKET table. |
| 181 | In this older style, new comments were added to tickets by using |
| 182 | the append-value feature on the comment field. Thus the TICKET.COMMENT |
| 183 | field contains the complete text of all user comments already appended |
| 184 | together and ready for display. |
| 185 | |
| 186 | A problem with the old approach is that all comment text had to |
| 187 | be in the same format. In other words, the all comment text had to be |
| 188 | either plaintext or wiki or HTML. It was not possible for some comments |
| 189 | to be in HTML and others to be plaintext. Some site adminstrators wanted the |
| 190 | ability to mix plaintext, wiki, and HTML comments and display each |
| 191 | comment according to its chosen format. Hence, Fossil was enhanced to |
| 192 | support the "new-style" tickets. |
| 193 | |
| 194 | The TICKETCHNG table was added to support new-style tickets. In the new |
| 195 | style, comment text is stored with the "icomment" (for "Incremental Comment") |
| 196 | key and appears separately, and with its on mimetype, in multiple rows |
| 197 | of the TICKETCHNG table. It then falls to the TH1 script code on the |
| 198 | View Ticket Page to query the TICKETCHNG table and extract and format |
| 199 | the various comments in timestamp order. |
| 200 |
| --- www/tickets.wiki | |
| +++ www/tickets.wiki | |
| @@ -101,20 +101,20 @@ | |
| 101 | used to uniquely identify the ticket to which the row belongs. These |
| 102 | keys are for internal use only and may change when doing a "fossil rebuild". |
| 103 | |
| 104 | The <b>tkt_uuid</b> field is the unique hexadecimal identifier for the ticket. |
| 105 | Ticket identifiers appear to be SHA1 hash strings, but they |
| 106 | are not really the hash of any identifiable artifact. They are |
| 107 | just random hexadecimal numbers. When creating a new ticket, Fossil uses |
| 108 | a (high-quality) pseudo-random number generator to create the ticket |
| 109 | number. The ticket numbers are large so that the chance of collision |
| 110 | between any two tickets is vanishingly small. |
| 111 | |
| 112 | The <b>tkt_mtime</b> field of TICKET shows the time (as a Julian day number) |
| 113 | of the most recent ticket change artifact for that ticket. The |
| 114 | <b>tkt_mtime</b> field of TICKETCHNG shows the timestamp on the ticket |
| 115 | change artifact that the TICKETCHNG row refers to. The |
| 116 | <b>tkt_ctime</b> field of TICKET is the time of the oldest ticket change |
| 117 | artifact for that ticket, thus holding the time that the ticket was |
| 118 | created. |
| 119 | |
| 120 | The <b>tkt_rid</b> field of TICKETCHNG is the integer primary key in the |
| @@ -160,11 +160,11 @@ | |
| 160 | visited, its key/value pairs are examined. For any key/value pair in |
| 161 | which the key is the same as a field in the TICKET table, the value |
| 162 | of that pair either replaces or is appended to the previous value |
| 163 | of the corresponding field in the TICKET table. Whether a value is |
| 164 | replaced or appended is determined by markings in the ticket change |
| 165 | artifact itself. Most fields are usually replaced. (For example, to change |
| 166 | the status from "Open" to "Fixed" would involve a key value pair |
| 167 | "status/Fixed" with the replace attribute set). The main exception |
| 168 | is the "comment" field, which is usually appended with new comment |
| 169 | text. |
| 170 | |
| @@ -174,26 +174,26 @@ | |
| 174 | difference there. |
| 175 | |
| 176 | <h3>2.3 Old-Style versus New-Style Tickets</h3> |
| 177 | |
| 178 | Older versions of Fossil |
| 179 | (before [/timeline?c=2012-11-27T16:26:29 | 2012-11-27]) |
| 180 | only supported the TICKET table. |
| 181 | In this older style, new comments were added to tickets by using |
| 182 | the append-value feature on the comment field. Thus the TICKET.COMMENT |
| 183 | field contains the complete text of all user comments already appended |
| 184 | together and ready for display. |
| 185 | |
| 186 | A problem with the old approach is that all comment text had to |
| 187 | be in the same format. In other words, the all comment text had to be |
| 188 | either plaintext or wiki or HTML. It was not possible for some comments |
| 189 | to be in HTML and others to be plaintext. Some site administrators wanted the |
| 190 | ability to mix plaintext, wiki, and HTML comments and display each |
| 191 | comment according to its chosen format. Hence, Fossil was enhanced to |
| 192 | support the "new-style" tickets. |
| 193 | |
| 194 | The TICKETCHNG table was added to support new-style tickets. In the new |
| 195 | style, comment text is stored with the "icomment" (for "Incremental Comment") |
| 196 | key and appears separately, and with its on mimetype, in multiple rows |
| 197 | of the TICKETCHNG table. It then falls to the TH1 script code on the |
| 198 | View Ticket Page to query the TICKETCHNG table and extract and format |
| 199 | the various comments in timestamp order. |
| 200 |