Differences From:
File www/bugtheory.wiki part of check-in [9d10726d48] - Documentation updates. by drh on 2008-07-29 13:07:17. [view]
To:
File www/bugtheory.wiki part of check-in [e8c4f69c50] - Change all mentions of "UUID" in the documentation and help screens into either "artifact ID" or "baseline ID" or "ticket ID" as appropriate. "UUID" has a widely recognized meaning that is different from its meaning in fossil. "UUID" is still used in code comments and in variable names. by drh on 2008-10-24 13:27:53. [view]
@@ -43,29 +43,29 @@ 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 @@ -95,9 +95,9 @@ 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