28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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
70
|
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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
70
|
-
+
-
-
+
+
-
-
-
-
-
-
+
+
+
+
+
+
|
<a href="fileformat.wiki">file format document</a> for details.)
Some artifacts have a special format, and among those are
<a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>.
One or more ticket change artifacts are associated with each
ticket. A ticket is created by a ticket change artifact.
Each subsequent modification of the ticket is a separate artifact.
The "push", "pull", and "sync" algorithms shared ticket change artifacts
The "push", "pull", and "sync" algorithms share ticket change artifacts
between repositories in the same way as every other artifact. In fact,
the sync algorithm has no knowledge of the meaning of the artifacts it
is syncing. As far as the sync algorithm is concerned, all artifacts are
alike. After the sync has occurs, the individual repositories must try
to make sense of the meaning of the various artifacts for themselves.
alike. After the sync has occurs, the individual repositories must
make sense of the meaning of the various artifacts for themselves.
<h2>Interpretation Of Ticket Change Artifacts</h2>
Every ticket change artifact contains (among other things)
* a timestamp,
* a ticket UUID, and
* one or more name/value pairs.
The current state of a ticket is found by replaying all ticket
change artifacts with the same ticket UUID in timestamp order.
For a given ticket, all values are initially NULL. As each
ticket change artifact is encountered, values are either replaced
or appended, according to a flag on the name/value pair. The current
values for the fields of a ticket are the values that remain at the
end of the replay process.
To create a new ticket, on has merely to insert a ticket change
artifact with a randomly generated ticket UUID. The ticket UUID
is a random 40-character lower-case hexadecimal number. New
ticket UUIDs should be chosen using good randomness so that two
ore more users do not accidently cause a conflict by generating
the same UUID. The name/value pairs on the initial ticket change
To create a new ticket, one inserts a ticket change
artifact with a new UUID. The ticket UUID
is a random 40-character lower-case hexadecimal number. The "tktnew"
page in the fossil web interface creates new ticket UUIDs
using a good source of randomness to insure uniqueness.
The name/value pairs on the initial ticket change
artifact are the initial values for the fields in the ticket.
Amending a ticket means simply creating a new artifact with the
same ticket UUID and with name/value pairs for those fields which
are changing. Fields of the ticket which are not being modified
should not appear as name/value pairs in the new artifact.
|
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
-
+
+
+
+
+
+
-
-
+
+
-
+
+
+
+
+
|
input formats and reporting rules according to its own particular needs.
Each repository defines its own TICKET table in its database. There is
one row in the TICKET table for each unique ticket UUID. The
names of columns in the TICKET table correspond to the names in
the name/value pairs of ticket change artifacts. When running the replay
algorithm, if a name/value pair is seen which has no corresponding column
in the TICKET table, then that name/value pair is ignored.
in the TICKET table, then that name/value pair is ignored. Columns can
be added or removed from the TICKET table at any time. Whenever the
TICKET table is modified, the replay algorithm automatically reruns
to repopulate the table using the new column names. Note that the TICKET
table schema and content is part of the local state of a respository
and is not shared with other repositories during a sync, push, or pull.
Each repository also defines scripts used to generate web pages for
creating new tickets, viewing existing tickets, and modifying an
existing ticket. These scripts consist of HTML with an embedded
scripts written an a TCL-like language called "TH1". Each fossil
repository is create with default scripts. There is currently no
scripts written an a TCL-like language called "TH1". Every new fossil
repository is created with default scripts. There is currently no
documentation on the TH1 langauage. Administrators wishing to
customize their ticket entry, viewing, and editing screens should
modify the default scripts to suit their needs.
modify the default scripts to suit their needs. These screen generator
scripts are part of the local state of a repository and are not shared
with other repositories during a sync, push, or pull.
<i>To be continued...</i>
|