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
71
72
73
74
|
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
71
72
73
74
|
-
+
-
+
-
+
-
+
-
+
|
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
* a ticket ID, 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.
change artifacts with the same ticket ID 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, one inserts a ticket change
artifact with a new UUID. The ticket UUID
artifact with a new ID. The ticket ID
is a random 40-character lower-case hexadecimal number. The "tktnew"
page in the fossil web interface creates new ticket UUIDs
page in the fossil web interface creates new ticket IDs
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
same ticket ID 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.
This approach to storing ticket state means that independently entered
changes are automatically merged together when artifacts are shared
between repositories. Tickets do not branch. This approach also makes
it trivial to track the historic progression of changes to a ticket.
|
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
-
+
|
a sync. Each repository also has local state which is not (normally)
shared. The name/value pairs for a ticket are part of global state,
but the interpretation and display of that information is local state.
Hence, each repository is free to set up its own ticket display and
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
one row in the TICKET table for each unique ticket ID. 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. 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
|