77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
add new ticket changes artifacts have to be set close to reality.
It is OK for a ticket change artifact timestamp to be off by a few
minutes or even a few hours. But if a timestamp on a ticket change
artifact is off by months or years, it can seriously confuse the
replay algorithm for determining the current ticket state. There
are techniques available to cause rogue artifacts to be ignored
by fossil. So if a ticket change artifact with a bad timestamp
does get into a repository, it can be removed by an adminstrator.
But the best approach is to take steps to insure that timestamps
are approximately correct in the first place.
<h2>Local Configuration</h2>
The ticket change artifacts are part of the global state for a project.
The global state is that which is shared between repositories during
|
|
|
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
add new ticket changes artifacts have to be set close to reality.
It is OK for a ticket change artifact timestamp to be off by a few
minutes or even a few hours. But if a timestamp on a ticket change
artifact is off by months or years, it can seriously confuse the
replay algorithm for determining the current ticket state. There
are techniques available to cause rogue artifacts to be ignored
by fossil. So if a ticket change artifact with a bad timestamp
does get into a repository, it can be removed by an administrator.
But the best approach is to take steps to insure that timestamps
are approximately correct in the first place.
<h2>Local Configuration</h2>
The ticket change artifacts are part of the global state for a project.
The global state is that which is shared between repositories during
|
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
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
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". 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. 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>
|
|
|
|
|
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
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
table schema and content is part of the local state of a repository
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". Every new fossil
repository is created with default scripts. There is currently no
documentation on the TH1 language. Administrators wishing to
customize their ticket entry, viewing, and editing screens should
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>
|