Not logged in
Check-in [68ce1305b1]

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment: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.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:68ce1305b106050d70b8fcac554125f368a5ab5a
User & Date: jan.nijtmans 2014-06-26 07:31:19
Context
2014-06-26
07:40
Make format parameter in socket_set_errmsg() and ssl_set_errmsg() functions a const. check-in: cfb8d6604f user: jan.nijtmans tags: trunk
07:31
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. check-in: 68ce1305b1 user: jan.nijtmans tags: trunk
2014-06-25
07:57
Add the .fullschema command to "fossil sqlite". This command shows the schema and the content of the sqlite_stat tables, all in one go. Useful when reporting problems with the query planner. check-in: 7ba8311e57 user: jan.nijtmans tags: trunk
Changes

Changes to test/graph-test-1.wiki.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<title>Graph Test One</title>

This page contains examples a list of URLs of timelines with
interesting graphs.  Click on all URLs, one by one, to verify 
the correct operation of the graph drawing logic.

  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08" target="testwindow">
     20-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08&ng" target="testwindow">
     20-element timeline, check-ins only, no graph, before 2010-11-08</a>
  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08&fc" target="testwindow">
     20-element timeline, check-ins only, file changes, before 2010-11-08</a>
  *  <a href="../../../timeline?n=40&y=ci&b=2010-11-08" target="testwindow">
     40-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=1000&y=ci&b=2010-11-08" target="testwindow">
     1000-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=10&c=2010-11-07+10:23:00" target="testwindow">
     10-elements circa 2010-11-07 10:23:00, with dividers</a>
  *  <a href="../../../timeline?n=10&c=2010-11-07+10:23:00&nd" 
     target="testwindow">
     10-elements circa 2010-11-07 10:23:00, without dividers</a>
  *  <a href="../../../timeline?f=3ea66260b5555" target="testwindow">
     Parents and children of check-in 3ea66260b5555</a>
  *  <a href="../../../timeline?d=e5fe4164f74a7576&p=e5fe4164f74a7576&n=3"
     target="testwindow">multiple merge descenders from the penultimate node.
     </a>
................................................................................
  *  <a href="../../../finfo?name=Makefile" target="testwindow">
     History of source file "Makefile".</a>
  *  <a href="../../../timeline?a=1970-01-01" target="testwindow">
     20 elements after 1970-01-01.</a>
  *  <a href="../../../timeline?n=100000000&y=ci" target="testwindow">
     All check-ins - a huge graph.</a>
  *  <a href="../../../timeline?f=8dfed953f7530442" target="testwindow">
     This malformed commit has a 
     merge parent which is not a valid checkin.</a>
  *  <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9"
     target="testwindow">
     From e663bac6f7 to a298a0e2f9 by shortest path.</a>
  *  <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9&nomerge"
     target="testwindow">
     From e663bac6f7 to a298a0e2f9 without merge links.</a>



|












|

|







 







|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
..
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
<title>Graph Test One</title>

This page contains examples a list of URLs of timelines with
interesting graphs.  Click on all URLs, one by one, to verify
the correct operation of the graph drawing logic.

  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08" target="testwindow">
     20-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08&ng" target="testwindow">
     20-element timeline, check-ins only, no graph, before 2010-11-08</a>
  *  <a href="../../../timeline?n=20&y=ci&b=2010-11-08&fc" target="testwindow">
     20-element timeline, check-ins only, file changes, before 2010-11-08</a>
  *  <a href="../../../timeline?n=40&y=ci&b=2010-11-08" target="testwindow">
     40-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=1000&y=ci&b=2010-11-08" target="testwindow">
     1000-element timeline, check-ins only, before 2010-11-08</a>
  *  <a href="../../../timeline?n=10&c=2010-11-07T10:23:00" target="testwindow">
     10-elements circa 2010-11-07 10:23:00, with dividers</a>
  *  <a href="../../../timeline?n=10&c=2010-11-07T10:23:00&nd"
     target="testwindow">
     10-elements circa 2010-11-07 10:23:00, without dividers</a>
  *  <a href="../../../timeline?f=3ea66260b5555" target="testwindow">
     Parents and children of check-in 3ea66260b5555</a>
  *  <a href="../../../timeline?d=e5fe4164f74a7576&p=e5fe4164f74a7576&n=3"
     target="testwindow">multiple merge descenders from the penultimate node.
     </a>
................................................................................
  *  <a href="../../../finfo?name=Makefile" target="testwindow">
     History of source file "Makefile".</a>
  *  <a href="../../../timeline?a=1970-01-01" target="testwindow">
     20 elements after 1970-01-01.</a>
  *  <a href="../../../timeline?n=100000000&y=ci" target="testwindow">
     All check-ins - a huge graph.</a>
  *  <a href="../../../timeline?f=8dfed953f7530442" target="testwindow">
     This malformed commit has a
     merge parent which is not a valid checkin.</a>
  *  <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9"
     target="testwindow">
     From e663bac6f7 to a298a0e2f9 by shortest path.</a>
  *  <a href="../../../timeline?from=e663bac6f7&to=a298a0e2f9&nomerge"
     target="testwindow">
     From e663bac6f7 to a298a0e2f9 without merge links.</a>

Changes to www/changes.wiki.

1
2
3
4
5
6
7
8

9
10
11
12
13
14
15
<title>Change Log</title>

<h2>Changes For Version 1.30 (as yet unreleased)</h2>
  *  Add setting to control the number of times autosync will be tried before
     returning an error.
  *  Add the "fossil fusefs DIRECTORY" command that mounts a Fuse Filesystem
     at the given DIRECTORY and populates it with read-only copies of all
     historical check-ins. This only works on systems that support FuseFS.

  *  Support customization of commands and webpages, including the ability to
     add new ones, via the "TH1 hooks" feature.  Disabled by default. Enabled
     via a compile-time option.
  *  Add the <nowiki>[checkout], [render], [styleHeader], [styleFooter],
     [trace], [getParameter], [setParameter], and [artifact]</nowiki> commands
     to TH1, primarily for use by TH1 hooks.
  *  Bring in the latest version of autosetup from upstream.





|
|
|
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<title>Change Log</title>

<h2>Changes For Version 1.30 (as yet unreleased)</h2>
  *  Add setting to control the number of times autosync will be tried before
     returning an error.
  *  Add the [/help/fusefs|fossil fusefs DIRECTORY] command that mounts a
     Fuse Filesystem at the given DIRECTORY and populates it with read-only
     copies of all historical check-ins. This only works on systems that
     support FuseFS.
  *  Support customization of commands and webpages, including the ability to
     add new ones, via the "TH1 hooks" feature.  Disabled by default. Enabled
     via a compile-time option.
  *  Add the <nowiki>[checkout], [render], [styleHeader], [styleFooter],
     [trace], [getParameter], [setParameter], and [artifact]</nowiki> commands
     to TH1, primarily for use by TH1 hooks.
  *  Bring in the latest version of autosetup from upstream.

Changes to www/fossil-v-git.wiki.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
..
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
..
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
...
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
...
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
...
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
...
214
215
216
217
218
219
220
221
222
223
224
225
226
227
<title>Fossil Versus Git</title>

<h2>1.0 Don't Stress!</h2>

If you start out using one DVCS and later decide you like the other better,
it is [./inout.wiki | easy to change].

But it also helps to be informed about the differences between 
[http://git-scm.com | Git] and Fossil.  See the table below for
a high-level summary and the text that follows for more details.

Keep in mind that you are reading this on a Fossil website, 
so the information here
might be biased in favor of Fossil.  Ask around with people who have
used both Fossil and Git for other opinions.

<h2>2.0 Executive Summary:</h2>

<blockquote><center><table border=1 cellpadding=5>
................................................................................
"[https://github.com/ | github]-in-a-box".

<h3>3.2 Sharding versus Replicating</h3>

Git makes it easy for each repository in a project to hold a subset of
the branches for that project.  In fact, it is entirely possible and not
uncommon for no repository in the project to hold all the different code
versions for a project.  Instead the information is distributed.  
Individual developers have one or more private branches.  A hierarchy
of integrators merge changes from individual developers into collaborative
branches, until all the changes are merged together at the top-level master
branch.  And all of this can be accomplished without having to have all the
code in any one repository.  Developers or groups of developers can share
only those branches that they want to share and keep other branchs of the
project private.  This is analogous to sharding an a distributed database.

Fossil allows private branches, but its default mode is to share everything.
And so in a Fossil project, all respositories tend to contain all of the
content at all times.  This is analogous to replication in a
distributed database.

The Git model works best for large projects, like the
Linux kernel for which Git was designed.
Linus Torvalds does not need or want to see a thousand
different branches, one for each contributor.  Git allows intermediary
................................................................................
into a single branch and only present Linus with a handful of branches
at a time.  Git encourages a programming model where each developer
works in his or her own branch and then merges changes up the hierarchy
until they reach the master branch.

Fossil is designed for smaller and non-hierarchical teams where all
developers are operating directly on the master branch, or at most
a small number of well defined branches.  
The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy
for multiple developers to work on a single branch and maintain
linear development on that branch and avoid needless forking
and merging.

<h3>3.3 Branches</h3>

Git (and especially GitHub) encourages a workflow where each developer 
has his or her own branch or branches.  Developers then send "pull requests"
to have their changes be merged into "official" branches by integrators.
For example, the Linux kernel team has a hierarchy of integrators with
Linus Torvalds at the root.  Individual developers each have their own
private branches of the source tree into which they make their own changes.
They then encourage first-tier integrators to pull those changes.  The
first-tier integrators merge together changes from multiple contributors
then try to get second-tier integrators to pull their branches.  The
changes merge up the hierarchy until (hopefully) they are pulled into 
"Linus's branch", at which time they become part of the "official" Linux.

In Git, each branch is "owned" by the person who creates it and works
on it.  The owner might pull changes from others, but the owner is always
in control of the branch.  Branches are developer-centric.

Fossil, on the other hand, encourages a workflow where branches are 
associated with features or releases, not individual developers.
All developers share all branches in common, and two
or more developers can and often do intersperse commits onto the same branch.
Branches do not belong to individuals.  All branches are read/write
accessible to all developers at all times.  There is no need
for integrators to merge together changes from various independent
developers.  Instead, all of the developers work together cooperatively
................................................................................

So to a first approximation, branches in Git are developer-centric whereas
branches in Fossil are feature-centric.

The Git approach scales much better for large projects like the Linux
kernel with thousands of contributors who in many cases don't even know
each others names.  The integrators serve a gatekeeper role to help keep
undesirable code out of the official Linux source tree.  On the other hand, 
not many projects are as big or as loosely organized as the Linux kernel.
Most projects have a small team of developers who all know each other
well and trust each other, and who enjoy working together collaboratively
without the overhead and hierarchy of integrators.

One consequence of the "everybody-sees-everything" focus of Fossil is that
branch names are global and are part of the distributed and synchronized
................................................................................
development.  One should not have to stop and think about how to operate
the VCS.  Of course, no VCS is ideal.  Every VCS requires the developer
to think about version control to some extent.  But one wants to minimize
the thinking about version control.

Git requires the developer to maintain a more complex mental model than
most other DVCSes.  Git takes longer to learn.  And you have to spend
more time thinking about what you are doing with Git.  

Fossil strives for simplicity.  Fossil wants to be easy to learn and to
require little thinking about how to operating it.  
[./quotes.wiki | Reports from the field]
indicate that Fossil is mostly successful at this effort.

<h3>3.5 Web Interface</h3>

Git has a web interface, but it requires a fair amount of setup and an
external web server.  Fossil comes with a fully functional
................................................................................

<h3>3.8 Audit Trail</h3>

Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository.  Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand.  This is important if you view the history of a project
as part of the documentation for the project.  

Fossil takes an opposing view.  Fossil views history as sacrosanct and
stubornly refuses to change it.
Fossil allows mistakes to be corrected (for example, check-in comments
can be revised, and check-ins can be moved onto new branches even after
the check-in has occurred) but the correction is an addition to the respository
and the original actions are preserved and displayed alongside
the corrections, thus preserving an historically accurate audit trail.
This is analogous to an accountant marking through an incorrect
entry in a ledger and writing in a correction beside it, rather than
erasing and incorrect entry.

To put it another way, Git remembers what you should have done whereas
................................................................................
Fossil remembers what you actually did.

The lack of a "rebase" command and the inability to rewrite history
is considered a feature of Fossil, not an omission or bug.

<h3>3.9 License</h3>

Both Git and Fossil are open-source.  Git is under 
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the 
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users.  However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.







|



|







 







|









|







 







|







|








|






|







 







|







 







|


|







 







|





|







 







|

|




1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
..
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
..
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
...
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
...
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
...
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
...
214
215
216
217
218
219
220
221
222
223
224
225
226
227
<title>Fossil Versus Git</title>

<h2>1.0 Don't Stress!</h2>

If you start out using one DVCS and later decide you like the other better,
it is [./inout.wiki | easy to change].

But it also helps to be informed about the differences between
[http://git-scm.com | Git] and Fossil.  See the table below for
a high-level summary and the text that follows for more details.

Keep in mind that you are reading this on a Fossil website,
so the information here
might be biased in favor of Fossil.  Ask around with people who have
used both Fossil and Git for other opinions.

<h2>2.0 Executive Summary:</h2>

<blockquote><center><table border=1 cellpadding=5>
................................................................................
"[https://github.com/ | github]-in-a-box".

<h3>3.2 Sharding versus Replicating</h3>

Git makes it easy for each repository in a project to hold a subset of
the branches for that project.  In fact, it is entirely possible and not
uncommon for no repository in the project to hold all the different code
versions for a project.  Instead the information is distributed.
Individual developers have one or more private branches.  A hierarchy
of integrators merge changes from individual developers into collaborative
branches, until all the changes are merged together at the top-level master
branch.  And all of this can be accomplished without having to have all the
code in any one repository.  Developers or groups of developers can share
only those branches that they want to share and keep other branchs of the
project private.  This is analogous to sharding an a distributed database.

Fossil allows private branches, but its default mode is to share everything.
And so in a Fossil project, all repositories tend to contain all of the
content at all times.  This is analogous to replication in a
distributed database.

The Git model works best for large projects, like the
Linux kernel for which Git was designed.
Linus Torvalds does not need or want to see a thousand
different branches, one for each contributor.  Git allows intermediary
................................................................................
into a single branch and only present Linus with a handful of branches
at a time.  Git encourages a programming model where each developer
works in his or her own branch and then merges changes up the hierarchy
until they reach the master branch.

Fossil is designed for smaller and non-hierarchical teams where all
developers are operating directly on the master branch, or at most
a small number of well defined branches.
The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy
for multiple developers to work on a single branch and maintain
linear development on that branch and avoid needless forking
and merging.

<h3>3.3 Branches</h3>

Git (and especially GitHub) encourages a workflow where each developer
has his or her own branch or branches.  Developers then send "pull requests"
to have their changes be merged into "official" branches by integrators.
For example, the Linux kernel team has a hierarchy of integrators with
Linus Torvalds at the root.  Individual developers each have their own
private branches of the source tree into which they make their own changes.
They then encourage first-tier integrators to pull those changes.  The
first-tier integrators merge together changes from multiple contributors
then try to get second-tier integrators to pull their branches.  The
changes merge up the hierarchy until (hopefully) they are pulled into
"Linus's branch", at which time they become part of the "official" Linux.

In Git, each branch is "owned" by the person who creates it and works
on it.  The owner might pull changes from others, but the owner is always
in control of the branch.  Branches are developer-centric.

Fossil, on the other hand, encourages a workflow where branches are
associated with features or releases, not individual developers.
All developers share all branches in common, and two
or more developers can and often do intersperse commits onto the same branch.
Branches do not belong to individuals.  All branches are read/write
accessible to all developers at all times.  There is no need
for integrators to merge together changes from various independent
developers.  Instead, all of the developers work together cooperatively
................................................................................

So to a first approximation, branches in Git are developer-centric whereas
branches in Fossil are feature-centric.

The Git approach scales much better for large projects like the Linux
kernel with thousands of contributors who in many cases don't even know
each others names.  The integrators serve a gatekeeper role to help keep
undesirable code out of the official Linux source tree.  On the other hand,
not many projects are as big or as loosely organized as the Linux kernel.
Most projects have a small team of developers who all know each other
well and trust each other, and who enjoy working together collaboratively
without the overhead and hierarchy of integrators.

One consequence of the "everybody-sees-everything" focus of Fossil is that
branch names are global and are part of the distributed and synchronized
................................................................................
development.  One should not have to stop and think about how to operate
the VCS.  Of course, no VCS is ideal.  Every VCS requires the developer
to think about version control to some extent.  But one wants to minimize
the thinking about version control.

Git requires the developer to maintain a more complex mental model than
most other DVCSes.  Git takes longer to learn.  And you have to spend
more time thinking about what you are doing with Git.

Fossil strives for simplicity.  Fossil wants to be easy to learn and to
require little thinking about how to operating it.
[./quotes.wiki | Reports from the field]
indicate that Fossil is mostly successful at this effort.

<h3>3.5 Web Interface</h3>

Git has a web interface, but it requires a fair amount of setup and an
external web server.  Fossil comes with a fully functional
................................................................................

<h3>3.8 Audit Trail</h3>

Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository.  Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand.  This is important if you view the history of a project
as part of the documentation for the project.

Fossil takes an opposing view.  Fossil views history as sacrosanct and
stubornly refuses to change it.
Fossil allows mistakes to be corrected (for example, check-in comments
can be revised, and check-ins can be moved onto new branches even after
the check-in has occurred) but the correction is an addition to the repository
and the original actions are preserved and displayed alongside
the corrections, thus preserving an historically accurate audit trail.
This is analogous to an accountant marking through an incorrect
entry in a ledger and writing in a correction beside it, rather than
erasing and incorrect entry.

To put it another way, Git remembers what you should have done whereas
................................................................................
Fossil remembers what you actually did.

The lack of a "rebase" command and the inability to rewrite history
is considered a feature of Fossil, not an omission or bug.

<h3>3.9 License</h3>

Both Git and Fossil are open-source.  Git is under
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users.  However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.

Changes to www/password.wiki.

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
..
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
...
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
...
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
Passwords are unique to each repository.  Passwords are not part of the
persistent state of a project.  Passwords are not versioned and
are not transmitted from one repository to another during a sync.
Passwords are local configuration information that can (and usually does)
vary from one repository to the next within the same project.

Passwords are stored in the PW field of the USER table.
In older versions of Fossil (prior to 
[/timeline?c=2010-01-10+20:56:30 | 2010-01-11]) the password 
is stored as cleartext.  In newer versions of Fossil, the password
can be either cleartext or an SHA1 hash (written as a 40-character
lower-case hexadecimal number).  If the USER.PW field contains
a 40-character string, that string is assumed to be a SHA1 hash.
If the size of USER.PW is anything other than 40 characters, then
it is understood as a plain-text password.

................................................................................
When a user logs into Fossil using the web interface, the login name
and password are sent in the clear to the server.  The server then
hashes the password and compares it against the value stored in USER.PW.
If they match, the server sets a cookie on the client to record the
login.  This cookie contains a large amount of high-quality randomness
and is thus intractable to guess.  The value of the cookie and the IP
address of the client is stored in the USER.COOKIE and USER.IPADDR fields
of the USER table on the server.  
The USER.CEXPIRE field holds an expiration date
for the cookie, encoded as a julian day number.  On all subsequent
HTTP requests, the cookie value is matched against the USER table to 
enable access to the repository.

A login cookie will only work if the IP address matches.  This feature
is designed to make it more difficult for an attacker to sniff the cookie
and take over the connection.  A cookie-sniffing attack will only work
if the attacker is able to send and receive from the same IP address as
the original login.  However, we found that doing an exact IP match
................................................................................
login attempt.  The plan moving forward is to compute the SHA1 hash of
the password on the client using javascript and then send only the hash
over the wire, but that plan has not yet been set in code.

<h2>Sync Protocol Authentication</h2>

A different authentication mechanism is used when one repository wants
to sync (or push or pull or clone) another respository.  When two
respositories are syncing, the one that initiates the transaction is
the client and the repository that responds is the server.  The client
works by sending HTTP requests to the server with a method of "xfer"
and a content-type of "application/x-fossil".  The content is Zlib-compressed
text consisting of "cards" of instructions.  The first card of this content
is a "login" card responsible for authentication.  The login card contains
the login name of the user and a "signature" where the signature is the
SHA1 hash of a nonce and the value of USER.PW.  The nonce is the
................................................................................
The client normally gets the login and password from the "remote URL".

<blockquote><pre>
http://<font color="blue">login:password</font>@servername.org/path
</pre></blockquote>

For older clients, the password is used for the shared secret as stated
in the URL and with no encoding.  
For newer clients, the shared secret is derived from the password 
by transformed the password using the SHA1 hash encoding
described above.  However, if the first character of the password is
"*" (ASCII 0x2a) then the "*" is skipped and the rest of the password
is used directly as the share secret without the SHA1 encoding.

<blockquote><pre>
http://<font color="blue">login:*password</font>@servername.org/path
</pre></blockquote>

This *-before-the-password trick can be used by newer clients to
sync against a legacy server that does not understand the new SHA1
password encoding.







|
|







 







|


|







 







|
|







 







|
|












5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
..
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
...
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
...
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
Passwords are unique to each repository.  Passwords are not part of the
persistent state of a project.  Passwords are not versioned and
are not transmitted from one repository to another during a sync.
Passwords are local configuration information that can (and usually does)
vary from one repository to the next within the same project.

Passwords are stored in the PW field of the USER table.
In older versions of Fossil (prior to
[/timeline?c=2010-01-10T20:56:30 | 2010-01-11]) the password
is stored as cleartext.  In newer versions of Fossil, the password
can be either cleartext or an SHA1 hash (written as a 40-character
lower-case hexadecimal number).  If the USER.PW field contains
a 40-character string, that string is assumed to be a SHA1 hash.
If the size of USER.PW is anything other than 40 characters, then
it is understood as a plain-text password.

................................................................................
When a user logs into Fossil using the web interface, the login name
and password are sent in the clear to the server.  The server then
hashes the password and compares it against the value stored in USER.PW.
If they match, the server sets a cookie on the client to record the
login.  This cookie contains a large amount of high-quality randomness
and is thus intractable to guess.  The value of the cookie and the IP
address of the client is stored in the USER.COOKIE and USER.IPADDR fields
of the USER table on the server.
The USER.CEXPIRE field holds an expiration date
for the cookie, encoded as a julian day number.  On all subsequent
HTTP requests, the cookie value is matched against the USER table to
enable access to the repository.

A login cookie will only work if the IP address matches.  This feature
is designed to make it more difficult for an attacker to sniff the cookie
and take over the connection.  A cookie-sniffing attack will only work
if the attacker is able to send and receive from the same IP address as
the original login.  However, we found that doing an exact IP match
................................................................................
login attempt.  The plan moving forward is to compute the SHA1 hash of
the password on the client using javascript and then send only the hash
over the wire, but that plan has not yet been set in code.

<h2>Sync Protocol Authentication</h2>

A different authentication mechanism is used when one repository wants
to sync (or push or pull or clone) another repository.  When two
repositories are syncing, the one that initiates the transaction is
the client and the repository that responds is the server.  The client
works by sending HTTP requests to the server with a method of "xfer"
and a content-type of "application/x-fossil".  The content is Zlib-compressed
text consisting of "cards" of instructions.  The first card of this content
is a "login" card responsible for authentication.  The login card contains
the login name of the user and a "signature" where the signature is the
SHA1 hash of a nonce and the value of USER.PW.  The nonce is the
................................................................................
The client normally gets the login and password from the "remote URL".

<blockquote><pre>
http://<font color="blue">login:password</font>@servername.org/path
</pre></blockquote>

For older clients, the password is used for the shared secret as stated
in the URL and with no encoding.
For newer clients, the shared secret is derived from the password
by transformed the password using the SHA1 hash encoding
described above.  However, if the first character of the password is
"*" (ASCII 0x2a) then the "*" is skipped and the rest of the password
is used directly as the share secret without the SHA1 encoding.

<blockquote><pre>
http://<font color="blue">login:*password</font>@servername.org/path
</pre></blockquote>

This *-before-the-password trick can be used by newer clients to
sync against a legacy server that does not understand the new SHA1
password encoding.

Changes to www/tickets.wiki.

99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
...
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199

The <b>tkt_id</b> fields of TICKET and TICKETCHNG are an integer key
used to uniquely identify the ticket to which the row belongs.  These
keys are for internal use only and may change when doing a "fossil rebuild".

The <b>tkt_uuid</b> field is the unique hexadecimal identifier for the ticket.
Ticket identifiers appear to be SHA1 hash strings, but they
are not really the hash of any identifible artifact.  They are
just random hexadecimal numbers.  When creating a new ticket, Fossil uses
a (high-quality) pseudo-random number generator to create the ticket 
number.  The ticket numbers are large so that the chance of collision
between any two tickets is vanishingly small.

The <b>tkt_mtime</b> field of TICKET shows the time (as a Julian day number)
of the most recent ticket change artifact for that ticket.  The
<b>tkt_mtime</b> field of TICKETCHNG shows the timestamp on the ticket
change artifact that the TICKETCHNG row refers to.  The 
<b>tkt_ctime</b> field of TICKET is the time of the oldest ticket change
artifact for that ticket, thus holding the time that the ticket was
created.

The <b>tkt_rid</b> field of TICKETCHNG is the integer primary key in the
BLOB table of the ticket change artifact that gave rise to the row in the
TICKETCHNG table.
................................................................................
To reconstruct the TICKET table, the ticket change
artifacts are visited in timestamp order.  As each ticket change artifact is
visited, its key/value pairs are examined.  For any key/value pair in
which the key is the same as a field in the TICKET table, the value
of that pair either replaces or is appended to the previous value
of the corresponding field in the TICKET table.  Whether a value is
replaced or appended is determined by markings in the ticket change
artifact itself.  Most fields are usually replaced. (For example, to change 
the status from "Open" to "Fixed" would involve a key value pair
"status/Fixed" with the replace attribute set).  The main exception
is the "comment" field, which is usually appended with new comment
text.

Note that the replace-or-append mark on ticket change artifacts is
only used by the TICKET table.  Since the initial value of all fields
in the TICKETCHNG table is NULL, the replace-or-append mark makes no
difference there.

<h3>2.3 Old-Style versus New-Style Tickets</h3>

Older versions of Fossil
(before [/timeline?c=2012-11-27+16:26:29 | 2012-11-27]) 
only supported the TICKET table.
In this older style, new comments were added to tickets by using
the append-value feature on the comment field.  Thus the TICKET.COMMENT
field contains the complete text of all user comments already appended
together and ready for display.

A problem with the old approach is that all comment text had to
be in the same format.  In other words, the all comment text had to be
either plaintext or wiki or HTML.  It was not possible for some comments
to be in HTML and others to be plaintext.  Some site adminstrators wanted the
ability to mix plaintext, wiki, and HTML comments and display each 
comment according to its chosen format.  Hence, Fossil was enhanced to
support the "new-style" tickets.

The TICKETCHNG table was added to support new-style tickets.  In the new
style, comment text is stored with the "icomment" (for "Incremental Comment")
key and appears separately, and with its on mimetype, in multiple rows
of the TICKETCHNG table.  It then falls to the TH1 script code on the
View Ticket Page to query the TICKETCHNG table and extract and format
the various comments in timestamp order.







|

|






|







 







|













|









|
|









99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
...
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199

The <b>tkt_id</b> fields of TICKET and TICKETCHNG are an integer key
used to uniquely identify the ticket to which the row belongs.  These
keys are for internal use only and may change when doing a "fossil rebuild".

The <b>tkt_uuid</b> field is the unique hexadecimal identifier for the ticket.
Ticket identifiers appear to be SHA1 hash strings, but they
are not really the hash of any identifiable artifact.  They are
just random hexadecimal numbers.  When creating a new ticket, Fossil uses
a (high-quality) pseudo-random number generator to create the ticket
number.  The ticket numbers are large so that the chance of collision
between any two tickets is vanishingly small.

The <b>tkt_mtime</b> field of TICKET shows the time (as a Julian day number)
of the most recent ticket change artifact for that ticket.  The
<b>tkt_mtime</b> field of TICKETCHNG shows the timestamp on the ticket
change artifact that the TICKETCHNG row refers to.  The
<b>tkt_ctime</b> field of TICKET is the time of the oldest ticket change
artifact for that ticket, thus holding the time that the ticket was
created.

The <b>tkt_rid</b> field of TICKETCHNG is the integer primary key in the
BLOB table of the ticket change artifact that gave rise to the row in the
TICKETCHNG table.
................................................................................
To reconstruct the TICKET table, the ticket change
artifacts are visited in timestamp order.  As each ticket change artifact is
visited, its key/value pairs are examined.  For any key/value pair in
which the key is the same as a field in the TICKET table, the value
of that pair either replaces or is appended to the previous value
of the corresponding field in the TICKET table.  Whether a value is
replaced or appended is determined by markings in the ticket change
artifact itself.  Most fields are usually replaced. (For example, to change
the status from "Open" to "Fixed" would involve a key value pair
"status/Fixed" with the replace attribute set).  The main exception
is the "comment" field, which is usually appended with new comment
text.

Note that the replace-or-append mark on ticket change artifacts is
only used by the TICKET table.  Since the initial value of all fields
in the TICKETCHNG table is NULL, the replace-or-append mark makes no
difference there.

<h3>2.3 Old-Style versus New-Style Tickets</h3>

Older versions of Fossil
(before [/timeline?c=2012-11-27T16:26:29 | 2012-11-27])
only supported the TICKET table.
In this older style, new comments were added to tickets by using
the append-value feature on the comment field.  Thus the TICKET.COMMENT
field contains the complete text of all user comments already appended
together and ready for display.

A problem with the old approach is that all comment text had to
be in the same format.  In other words, the all comment text had to be
either plaintext or wiki or HTML.  It was not possible for some comments
to be in HTML and others to be plaintext.  Some site administrators wanted the
ability to mix plaintext, wiki, and HTML comments and display each
comment according to its chosen format.  Hence, Fossil was enhanced to
support the "new-style" tickets.

The TICKETCHNG table was added to support new-style tickets.  In the new
style, comment text is stored with the "icomment" (for "Incremental Comment")
key and appears separately, and with its on mimetype, in multiple rows
of the TICKETCHNG table.  It then falls to the TH1 script code on the
View Ticket Page to query the TICKETCHNG table and extract and format
the various comments in timestamp order.