| ︙ | | | ︙ | |
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
<blockquote><pre>
fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
</pre></blockquote>
The full 40-character SHA1 hash is unwieldy to remember and type, though,
so Fossil also accepts a unique prefix of the hash, using any combination
of upper and lower case letters, as long as the prefix is at least 4
characters long. Hence the following commands all
accomplish the same thing as the above:
<blockquote><pre>
fossil info e5a734a19a9
fossil info E5a734A
fossil info e5a7
</blockquote>
Many web-interface screens identify check-ins by 10- or 16-character
prefix of canonical name.
<h2>Tags And Branch Names</h2>
Using a tag or branch name where a check-in name is expected causes
Fossil to choose the most recent check-in with that tag or branch name.
So, for example, as of this writing the most recent check-in that
|
|
|
|
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
<blockquote><pre>
fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
</pre></blockquote>
The full 40-character SHA1 hash is unwieldy to remember and type, though,
so Fossil also accepts a unique prefix of the hash, using any combination
of upper and lower case letters, as long as the prefix is at least 4
characters long. Hence the following commands all
accomplish the same thing as the above:
<blockquote><pre>
fossil info e5a734a19a9
fossil info E5a734A
fossil info e5a7
</blockquote>
Many web-interface screens identify check-ins by 10- or 16-character
prefix of canonical name.
<h2>Tags And Branch Names</h2>
Using a tag or branch name where a check-in name is expected causes
Fossil to choose the most recent check-in with that tag or branch name.
So, for example, as of this writing the most recent check-in that
|
| ︙ | | | ︙ | |
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
name? In such cases, you can prefix the tag name with "tag:".
For example:
<blockquote><tt>
fossil info tag:deed2
</tt></blockquote>
The "tag:deed2" name will refer to the most recent check-in
tagged with "deed2" not to the
check-in whose canonical name begins with "deed2".
<h2>Whole Branches</h2>
Usually when a branch name is specified, it means the latest check-in on
that branch. But for some commands (ex: [/help/purge|purge]) a branch name
|
|
|
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
name? In such cases, you can prefix the tag name with "tag:".
For example:
<blockquote><tt>
fossil info tag:deed2
</tt></blockquote>
The "tag:deed2" name will refer to the most recent check-in
tagged with "deed2" not to the
check-in whose canonical name begins with "deed2".
<h2>Whole Branches</h2>
Usually when a branch name is specified, it means the latest check-in on
that branch. But for some commands (ex: [/help/purge|purge]) a branch name
|
| ︙ | | | ︙ | |
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
check-in that occurs no later than the timestamp given:
* <i>YYYY-MM-DD</i>
* <i>YYYY-MM-DD HH:MM</i>
* <i>YYYY-MM-DD HH:MM:SS</i>
* <i>YYYY-MM-DD HH:MM:SS.SSS</i>
The space between the day and the year can optionally be
replaced by an uppercase <b>T</b> and the entire timestamp can
optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
form with fractional seconds, any number of digits may follow the
decimal point, though due to precision limits only the first three
digits will be significant.
In its default configuration, Fossil interprets and displays all dates
in Universal Coordinated Time (UTC). This tends to work the best for
distributed projects where participants are scattered around the globe.
But there is an option on the Admin/Timeline page of the web-interface to
switch to local time. The "<b>Z</b>" suffix on a timestamp check-in
name is meaningless if Fossil is in the default mode of using UTC for
everything, but if Fossil has been switched to local time mode, then the
"<b>Z</b>" suffix means to interpret that particular timestamp using
UTC instead of local time.
For an example of how timestamps are useful,
consider the homepage for the Fossil website itself:
<blockquote>
http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki
</blockquote>
The bold component of that URL is a check-in name. To see what the
|
|
|
|
|
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
check-in that occurs no later than the timestamp given:
* <i>YYYY-MM-DD</i>
* <i>YYYY-MM-DD HH:MM</i>
* <i>YYYY-MM-DD HH:MM:SS</i>
* <i>YYYY-MM-DD HH:MM:SS.SSS</i>
The space between the day and the year can optionally be
replaced by an uppercase <b>T</b> and the entire timestamp can
optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
form with fractional seconds, any number of digits may follow the
decimal point, though due to precision limits only the first three
digits will be significant.
In its default configuration, Fossil interprets and displays all dates
in Universal Coordinated Time (UTC). This tends to work the best for
distributed projects where participants are scattered around the globe.
But there is an option on the Admin/Timeline page of the web-interface to
switch to local time. The "<b>Z</b>" suffix on a timestamp check-in
name is meaningless if Fossil is in the default mode of using UTC for
everything, but if Fossil has been switched to local time mode, then the
"<b>Z</b>" suffix means to interpret that particular timestamp using
UTC instead of local time.
For an example of how timestamps are useful,
consider the homepage for the Fossil website itself:
<blockquote>
http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki
</blockquote>
The bold component of that URL is a check-in name. To see what the
|
| ︙ | | | ︙ | |
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
the timestamp. So, for example:
<blockquote>
fossil update trunk:2010-07-01T14:30
</blockquote>
Would cause Fossil to update the working check-out to be the most recent
check-in on the trunk that is not more recent that 14:30 (UTC) on
July 1, 2010.
<h2>Root Of A Branch</h2>
A branch name that begins with the "<tt>root:</tt>" prefix refers to the
last check-in in the parent branch prior to the beginning of the branch.
Such a label is useful, for example, in computing all diffs for a single
|
|
|
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
the timestamp. So, for example:
<blockquote>
fossil update trunk:2010-07-01T14:30
</blockquote>
Would cause Fossil to update the working check-out to be the most recent
check-in on the trunk that is not more recent that 14:30 (UTC) on
July 1, 2010.
<h2>Root Of A Branch</h2>
A branch name that begins with the "<tt>root:</tt>" prefix refers to the
last check-in in the parent branch prior to the beginning of the branch.
Such a label is useful, for example, in computing all diffs for a single
|
| ︙ | | | ︙ | |
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
repository) then a few extra tags apply. The "current" tag means the
current check-out. The "next" tag means the youngest child of the
current check-out. And the "previous" or "prev" tag means the primary
(non-merge) parent of the current check-out.
For embedded documentation, the tag "ckout" means the version as present in
the local source tree on disk, provided that the web server is started using
"fossil ui" or "fossil server" from within the source tree. This tag can be
used to preview local changes to documentation before committing them. It does
not apply to CLI commands.
<h2>Additional Examples</h2>
To view the changes in the most recent check-in prior to the version currently
checked out:
|
|
|
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
repository) then a few extra tags apply. The "current" tag means the
current check-out. The "next" tag means the youngest child of the
current check-out. And the "previous" or "prev" tag means the primary
(non-merge) parent of the current check-out.
For embedded documentation, the tag "ckout" means the version as present in
the local source tree on disk, provided that the web server is started using
"fossil ui" or "fossil server" from within the source tree. This tag can be
used to preview local changes to documentation before committing them. It does
not apply to CLI commands.
<h2>Additional Examples</h2>
To view the changes in the most recent check-in prior to the version currently
checked out:
|
| ︙ | | | ︙ | |