Fossil SCM
In www/checkin_names.wiki, documented the date: prefix for timetsamps, added fragment IDs for subsections, added a differentiating example of "fossil info" vs "/info/NAME" for special check-in names, and documented the order that Fossil resolves such names.
Commit
74a7309aad8d296997a0141bb67df1ca226f2e52c4093effd6c2c80346b66d5f
Parent
51511b7205f6046…
1 file changed
+60
-20
+60
-20
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -42,11 +42,11 @@ | ||
| 42 | 42 | determines which version of the documentation to display. |
| 43 | 43 | |
| 44 | 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | 45 | document describes the various methods. |
| 46 | 46 | |
| 47 | -<h2>Canonical Check-in Name</h2> | |
| 47 | +<h2 id="canonical">Canonical Check-in Name</h2> | |
| 48 | 48 | |
| 49 | 49 | The canonical name of a check-in is the hash of its |
| 50 | 50 | [./fileformat.wiki#manifest | manifest] expressed as a 40-or-more character |
| 51 | 51 | lowercase hexadecimal number. For example: |
| 52 | 52 | |
| @@ -67,11 +67,11 @@ | ||
| 67 | 67 | </blockquote> |
| 68 | 68 | |
| 69 | 69 | Many web-interface screens identify check-ins by 10- or 16-character |
| 70 | 70 | prefix of canonical name. |
| 71 | 71 | |
| 72 | -<h2>Tags And Branch Names</h2> | |
| 72 | +<h2 id="tags">Tags And Branch Names</h2> | |
| 73 | 73 | |
| 74 | 74 | Using a tag or branch name where a check-in name is expected causes |
| 75 | 75 | Fossil to choose the most recent check-in with that tag or branch name. |
| 76 | 76 | So, for example, as of this writing the most recent check-in that |
| 77 | 77 | is tagged with "release" is [d0753799e44]. |
| @@ -100,10 +100,11 @@ | ||
| 100 | 100 | Note that unlike other command DVCSes, a "branch" in Fossil |
| 101 | 101 | is not anything special; it is simply a sequence of check-ins that |
| 102 | 102 | share a common tag. So the same mechanism that resolves tag names |
| 103 | 103 | also resolves branch names. |
| 104 | 104 | |
| 105 | +<a id="tagpfx"></a> | |
| 105 | 106 | Note also that there can (in theory) be an ambiguity between tag names |
| 106 | 107 | and canonical names. Suppose, for example, you had a check-in with |
| 107 | 108 | the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you |
| 108 | 109 | also happened to have tagged a different check-in with "deed2". If |
| 109 | 110 | you use the "deed2" name, does it choose the canonical name or the tag |
| @@ -116,11 +117,11 @@ | ||
| 116 | 117 | |
| 117 | 118 | The "tag:deed2" name will refer to the most recent check-in |
| 118 | 119 | tagged with "deed2" not to the |
| 119 | 120 | check-in whose canonical name begins with "deed2". |
| 120 | 121 | |
| 121 | -<h2>Whole Branches</h2> | |
| 122 | +<h2 id="whole-branches">Whole Branches</h2> | |
| 122 | 123 | |
| 123 | 124 | Usually when a branch name is specified, it means the latest check-in on |
| 124 | 125 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 125 | 126 | on the argument means the earliest connected check-in on the branch. This |
| 126 | 127 | seems confusing when being explained here, but it works out to be intuitive |
| @@ -137,11 +138,11 @@ | ||
| 137 | 138 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 138 | 139 | back down the branch looking for the first check-in of that branch. |
| 139 | 140 | |
| 140 | 141 | Again, this behavior only occurs on a few commands where it make sense. |
| 141 | 142 | |
| 142 | -<h2>Timestamps</h2> | |
| 143 | +<h2 id="timestamps">Timestamps</h2> | |
| 143 | 144 | |
| 144 | 145 | A timestamp in one of the formats shown below means the most recent |
| 145 | 146 | check-in that occurs no later than the timestamp given: |
| 146 | 147 | |
| 147 | 148 | 1. <i>YYYY-MM-DD</i> |
| @@ -170,10 +171,18 @@ | ||
| 170 | 171 | name is meaningless if Fossil is in the default mode of using UTC for |
| 171 | 172 | everything, but if Fossil has been switched to local time mode, then the |
| 172 | 173 | "<b>Z</b>" suffix means to interpret that particular timestamp using |
| 173 | 174 | UTC instead of local time. |
| 174 | 175 | |
| 176 | +You may prefix a timestamp with the string “date:”, in which case | |
| 177 | +processing stops immediately, whether the string is parsed correctly and | |
| 178 | +refers to anything within the repository or not. The prefix is therefore | |
| 179 | +useful when the date could be misinterpreted as a tag. For example, a | |
| 180 | +repo could have release tags like “2020-04-01”, the date the release was | |
| 181 | +cut, but you could force Fossil to interpret that string as a date | |
| 182 | +rather than as a tag by passing “date:2020-04-01”. | |
| 183 | + | |
| 175 | 184 | For an example of how timestamps are useful, |
| 176 | 185 | consider the homepage for the Fossil website itself: |
| 177 | 186 | |
| 178 | 187 | <blockquote> |
| 179 | 188 | http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki |
| @@ -185,11 +194,11 @@ | ||
| 185 | 194 | |
| 186 | 195 | <blockquote> |
| 187 | 196 | http://www.fossil-scm.org/fossil/doc/<b>2009-01-01</b>/www/index.wiki |
| 188 | 197 | </blockquote> |
| 189 | 198 | |
| 190 | -<h2>Tag And Timestamp</h2> | |
| 199 | +<h2 id="tag-ts">Tag And Timestamp</h2> | |
| 191 | 200 | |
| 192 | 201 | A check-in name can also take the form of a tag or branch name followed by |
| 193 | 202 | a colon and then a timestamp. The combination means to take the most |
| 194 | 203 | recent check-in with the given tag or branch which is not more recent than |
| 195 | 204 | the timestamp. So, for example: |
| @@ -200,11 +209,11 @@ | ||
| 200 | 209 | |
| 201 | 210 | Would cause Fossil to update the working check-out to be the most recent |
| 202 | 211 | check-in on the trunk that is not more recent that 14:30 (UTC) on |
| 203 | 212 | July 1, 2010. |
| 204 | 213 | |
| 205 | -<h2>Root Of A Branch</h2> | |
| 214 | +<h2 id="root">Root Of A Branch</h2> | |
| 206 | 215 | |
| 207 | 216 | A branch name that begins with the "<tt>root:</tt>" prefix refers to the |
| 208 | 217 | last check-in in the parent branch prior to the beginning of the branch. |
| 209 | 218 | Such a label is useful, for example, in computing all diffs for a single |
| 210 | 219 | branch. The following example will show all changes in the hypothetical |
| @@ -212,35 +221,48 @@ | ||
| 212 | 221 | |
| 213 | 222 | <blockquote> |
| 214 | 223 | fossil diff --from root:xyzzy --to xyzzy |
| 215 | 224 | </blockquote> |
| 216 | 225 | |
| 226 | +<a id="merge-in"></a> | |
| 217 | 227 | A branch name that begins with the "<tt>merge-in:</tt>" prefix refers not |
| 218 | 228 | to the root of the branch, but to the most recent merge-in for that branch |
| 219 | 229 | from its parent. The most recent merge-in is the version to diff the branch |
| 220 | 230 | against in order to see all changes in just the branch itself, omitting |
| 221 | 231 | any changes that have already been merged in from the parent branch. |
| 222 | 232 | |
| 223 | 233 | |
| 224 | -<h2>Special Tags</h2> | |
| 234 | +<h2 id="special">Special Tags</h2> | |
| 225 | 235 | |
| 226 | 236 | The tag "tip" means the most recent check-in. The "tip" tag is roughly |
| 227 | 237 | equivalent to the timestamp tag "5000-01-01". |
| 228 | 238 | |
| 229 | -If the command is being run from a working check-out (not against a bare | |
| 230 | -repository) then a few extra tags apply. The "current" tag means the | |
| 231 | -current check-out. The "next" tag means the youngest child of the | |
| 232 | -current check-out. And the "previous" or "prev" tag means the primary | |
| 233 | -(non-merge) parent of the current check-out. | |
| 234 | - | |
| 235 | -For embedded documentation, the tag "ckout" means the version as present in | |
| 236 | -the local source tree on disk, provided that the web server is started using | |
| 237 | -"fossil ui" or "fossil server" from within the source tree. This tag can be | |
| 238 | -used to preview local changes to documentation before committing them. It does | |
| 239 | -not apply to CLI commands. | |
| 240 | - | |
| 241 | -<h2>Additional Examples</h2> | |
| 239 | +This special name works anywhere you can pass a "NAME", such as in in | |
| 240 | +<tt>/info</tt> URLs: | |
| 241 | + | |
| 242 | +<blockquote><pre> | |
| 243 | +http://localhost:8080/info/tip | |
| 244 | +</pre></blockquote> | |
| 245 | + | |
| 246 | +There are several other special names, but they only work from within a | |
| 247 | +check-out directory because they are relative to the current checked-out | |
| 248 | +version: | |
| 249 | + | |
| 250 | + * "current": the current checked-out version | |
| 251 | + * "next": the youngest child of the current checked-out version | |
| 252 | + * "previous" or "prev": the primary (non-merge) parent of "current" | |
| 253 | + | |
| 254 | +Therefore, you can use these names in a <tt>fossil info</tt> command, | |
| 255 | +but not in an <tt>/info</tt> URL, for example. | |
| 256 | + | |
| 257 | +For embedded documentation URLs only, there is one more special name, | |
| 258 | +"ckout". See [./embeddeddoc.wiki#ckout | its coverage elsewhere] for | |
| 259 | +more details. You cannot currently use "ckout" anywhere other than in | |
| 260 | +<tt>/doc</tt> URLs. | |
| 261 | + | |
| 262 | + | |
| 263 | +<h2 id="examples">Additional Examples</h2> | |
| 242 | 264 | |
| 243 | 265 | To view the changes in the most recent check-in prior to the version currently |
| 244 | 266 | checked out: |
| 245 | 267 | |
| 246 | 268 | <blockquote><pre> |
| @@ -251,5 +273,23 @@ | ||
| 251 | 273 | Then to see everything that has changed on the trunk since the last release: |
| 252 | 274 | |
| 253 | 275 | <blockquote><pre> |
| 254 | 276 | fossil diff --from release --to trunk |
| 255 | 277 | </pre></blockquote> |
| 278 | + | |
| 279 | + | |
| 280 | +<h2 id="order">Resolution Order</h2> | |
| 281 | + | |
| 282 | +Fossil currently resolves name strings to artifact hashes in the | |
| 283 | +following order: | |
| 284 | + | |
| 285 | + # Exact matches on [#special | the special names] | |
| 286 | + # [#timestamps | Timestamps], with preference to ISO8601 forms | |
| 287 | + # [#tagpfx | tag:TAGNAME] | |
| 288 | + # [#root | root:BRANCH] | |
| 289 | + # [#merge-in | merge-in:BRANCH] | |
| 290 | + # [#tag-ts | TAG:timestamp] | |
| 291 | + # Full artifact hash or hash prefix. | |
| 292 | + # Any other type of symbolic name that Fossil extracts from | |
| 293 | + blockchain artifacts. | |
| 294 | + | |
| 295 | +<div style="height:40em" id="this-space-intentionally-left-blank"></div> | |
| 256 | 296 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -42,11 +42,11 @@ | |
| 42 | determines which version of the documentation to display. |
| 43 | |
| 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | document describes the various methods. |
| 46 | |
| 47 | <h2>Canonical Check-in Name</h2> |
| 48 | |
| 49 | The canonical name of a check-in is the hash of its |
| 50 | [./fileformat.wiki#manifest | manifest] expressed as a 40-or-more character |
| 51 | lowercase hexadecimal number. For example: |
| 52 | |
| @@ -67,11 +67,11 @@ | |
| 67 | </blockquote> |
| 68 | |
| 69 | Many web-interface screens identify check-ins by 10- or 16-character |
| 70 | prefix of canonical name. |
| 71 | |
| 72 | <h2>Tags And Branch Names</h2> |
| 73 | |
| 74 | Using a tag or branch name where a check-in name is expected causes |
| 75 | Fossil to choose the most recent check-in with that tag or branch name. |
| 76 | So, for example, as of this writing the most recent check-in that |
| 77 | is tagged with "release" is [d0753799e44]. |
| @@ -100,10 +100,11 @@ | |
| 100 | Note that unlike other command DVCSes, a "branch" in Fossil |
| 101 | is not anything special; it is simply a sequence of check-ins that |
| 102 | share a common tag. So the same mechanism that resolves tag names |
| 103 | also resolves branch names. |
| 104 | |
| 105 | Note also that there can (in theory) be an ambiguity between tag names |
| 106 | and canonical names. Suppose, for example, you had a check-in with |
| 107 | the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you |
| 108 | also happened to have tagged a different check-in with "deed2". If |
| 109 | you use the "deed2" name, does it choose the canonical name or the tag |
| @@ -116,11 +117,11 @@ | |
| 116 | |
| 117 | The "tag:deed2" name will refer to the most recent check-in |
| 118 | tagged with "deed2" not to the |
| 119 | check-in whose canonical name begins with "deed2". |
| 120 | |
| 121 | <h2>Whole Branches</h2> |
| 122 | |
| 123 | Usually when a branch name is specified, it means the latest check-in on |
| 124 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 125 | on the argument means the earliest connected check-in on the branch. This |
| 126 | seems confusing when being explained here, but it works out to be intuitive |
| @@ -137,11 +138,11 @@ | |
| 137 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 138 | back down the branch looking for the first check-in of that branch. |
| 139 | |
| 140 | Again, this behavior only occurs on a few commands where it make sense. |
| 141 | |
| 142 | <h2>Timestamps</h2> |
| 143 | |
| 144 | A timestamp in one of the formats shown below means the most recent |
| 145 | check-in that occurs no later than the timestamp given: |
| 146 | |
| 147 | 1. <i>YYYY-MM-DD</i> |
| @@ -170,10 +171,18 @@ | |
| 170 | name is meaningless if Fossil is in the default mode of using UTC for |
| 171 | everything, but if Fossil has been switched to local time mode, then the |
| 172 | "<b>Z</b>" suffix means to interpret that particular timestamp using |
| 173 | UTC instead of local time. |
| 174 | |
| 175 | For an example of how timestamps are useful, |
| 176 | consider the homepage for the Fossil website itself: |
| 177 | |
| 178 | <blockquote> |
| 179 | http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki |
| @@ -185,11 +194,11 @@ | |
| 185 | |
| 186 | <blockquote> |
| 187 | http://www.fossil-scm.org/fossil/doc/<b>2009-01-01</b>/www/index.wiki |
| 188 | </blockquote> |
| 189 | |
| 190 | <h2>Tag And Timestamp</h2> |
| 191 | |
| 192 | A check-in name can also take the form of a tag or branch name followed by |
| 193 | a colon and then a timestamp. The combination means to take the most |
| 194 | recent check-in with the given tag or branch which is not more recent than |
| 195 | the timestamp. So, for example: |
| @@ -200,11 +209,11 @@ | |
| 200 | |
| 201 | Would cause Fossil to update the working check-out to be the most recent |
| 202 | check-in on the trunk that is not more recent that 14:30 (UTC) on |
| 203 | July 1, 2010. |
| 204 | |
| 205 | <h2>Root Of A Branch</h2> |
| 206 | |
| 207 | A branch name that begins with the "<tt>root:</tt>" prefix refers to the |
| 208 | last check-in in the parent branch prior to the beginning of the branch. |
| 209 | Such a label is useful, for example, in computing all diffs for a single |
| 210 | branch. The following example will show all changes in the hypothetical |
| @@ -212,35 +221,48 @@ | |
| 212 | |
| 213 | <blockquote> |
| 214 | fossil diff --from root:xyzzy --to xyzzy |
| 215 | </blockquote> |
| 216 | |
| 217 | A branch name that begins with the "<tt>merge-in:</tt>" prefix refers not |
| 218 | to the root of the branch, but to the most recent merge-in for that branch |
| 219 | from its parent. The most recent merge-in is the version to diff the branch |
| 220 | against in order to see all changes in just the branch itself, omitting |
| 221 | any changes that have already been merged in from the parent branch. |
| 222 | |
| 223 | |
| 224 | <h2>Special Tags</h2> |
| 225 | |
| 226 | The tag "tip" means the most recent check-in. The "tip" tag is roughly |
| 227 | equivalent to the timestamp tag "5000-01-01". |
| 228 | |
| 229 | If the command is being run from a working check-out (not against a bare |
| 230 | repository) then a few extra tags apply. The "current" tag means the |
| 231 | current check-out. The "next" tag means the youngest child of the |
| 232 | current check-out. And the "previous" or "prev" tag means the primary |
| 233 | (non-merge) parent of the current check-out. |
| 234 | |
| 235 | For embedded documentation, the tag "ckout" means the version as present in |
| 236 | the local source tree on disk, provided that the web server is started using |
| 237 | "fossil ui" or "fossil server" from within the source tree. This tag can be |
| 238 | used to preview local changes to documentation before committing them. It does |
| 239 | not apply to CLI commands. |
| 240 | |
| 241 | <h2>Additional Examples</h2> |
| 242 | |
| 243 | To view the changes in the most recent check-in prior to the version currently |
| 244 | checked out: |
| 245 | |
| 246 | <blockquote><pre> |
| @@ -251,5 +273,23 @@ | |
| 251 | Then to see everything that has changed on the trunk since the last release: |
| 252 | |
| 253 | <blockquote><pre> |
| 254 | fossil diff --from release --to trunk |
| 255 | </pre></blockquote> |
| 256 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -42,11 +42,11 @@ | |
| 42 | determines which version of the documentation to display. |
| 43 | |
| 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | document describes the various methods. |
| 46 | |
| 47 | <h2 id="canonical">Canonical Check-in Name</h2> |
| 48 | |
| 49 | The canonical name of a check-in is the hash of its |
| 50 | [./fileformat.wiki#manifest | manifest] expressed as a 40-or-more character |
| 51 | lowercase hexadecimal number. For example: |
| 52 | |
| @@ -67,11 +67,11 @@ | |
| 67 | </blockquote> |
| 68 | |
| 69 | Many web-interface screens identify check-ins by 10- or 16-character |
| 70 | prefix of canonical name. |
| 71 | |
| 72 | <h2 id="tags">Tags And Branch Names</h2> |
| 73 | |
| 74 | Using a tag or branch name where a check-in name is expected causes |
| 75 | Fossil to choose the most recent check-in with that tag or branch name. |
| 76 | So, for example, as of this writing the most recent check-in that |
| 77 | is tagged with "release" is [d0753799e44]. |
| @@ -100,10 +100,11 @@ | |
| 100 | Note that unlike other command DVCSes, a "branch" in Fossil |
| 101 | is not anything special; it is simply a sequence of check-ins that |
| 102 | share a common tag. So the same mechanism that resolves tag names |
| 103 | also resolves branch names. |
| 104 | |
| 105 | <a id="tagpfx"></a> |
| 106 | Note also that there can (in theory) be an ambiguity between tag names |
| 107 | and canonical names. Suppose, for example, you had a check-in with |
| 108 | the canonical name deed28aa99a835f01fa06d5b4a41ecc2121bf419 and you |
| 109 | also happened to have tagged a different check-in with "deed2". If |
| 110 | you use the "deed2" name, does it choose the canonical name or the tag |
| @@ -116,11 +117,11 @@ | |
| 117 | |
| 118 | The "tag:deed2" name will refer to the most recent check-in |
| 119 | tagged with "deed2" not to the |
| 120 | check-in whose canonical name begins with "deed2". |
| 121 | |
| 122 | <h2 id="whole-branches">Whole Branches</h2> |
| 123 | |
| 124 | Usually when a branch name is specified, it means the latest check-in on |
| 125 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 126 | on the argument means the earliest connected check-in on the branch. This |
| 127 | seems confusing when being explained here, but it works out to be intuitive |
| @@ -137,11 +138,11 @@ | |
| 138 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 139 | back down the branch looking for the first check-in of that branch. |
| 140 | |
| 141 | Again, this behavior only occurs on a few commands where it make sense. |
| 142 | |
| 143 | <h2 id="timestamps">Timestamps</h2> |
| 144 | |
| 145 | A timestamp in one of the formats shown below means the most recent |
| 146 | check-in that occurs no later than the timestamp given: |
| 147 | |
| 148 | 1. <i>YYYY-MM-DD</i> |
| @@ -170,10 +171,18 @@ | |
| 171 | name is meaningless if Fossil is in the default mode of using UTC for |
| 172 | everything, but if Fossil has been switched to local time mode, then the |
| 173 | "<b>Z</b>" suffix means to interpret that particular timestamp using |
| 174 | UTC instead of local time. |
| 175 | |
| 176 | You may prefix a timestamp with the string “date:”, in which case |
| 177 | processing stops immediately, whether the string is parsed correctly and |
| 178 | refers to anything within the repository or not. The prefix is therefore |
| 179 | useful when the date could be misinterpreted as a tag. For example, a |
| 180 | repo could have release tags like “2020-04-01”, the date the release was |
| 181 | cut, but you could force Fossil to interpret that string as a date |
| 182 | rather than as a tag by passing “date:2020-04-01”. |
| 183 | |
| 184 | For an example of how timestamps are useful, |
| 185 | consider the homepage for the Fossil website itself: |
| 186 | |
| 187 | <blockquote> |
| 188 | http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki |
| @@ -185,11 +194,11 @@ | |
| 194 | |
| 195 | <blockquote> |
| 196 | http://www.fossil-scm.org/fossil/doc/<b>2009-01-01</b>/www/index.wiki |
| 197 | </blockquote> |
| 198 | |
| 199 | <h2 id="tag-ts">Tag And Timestamp</h2> |
| 200 | |
| 201 | A check-in name can also take the form of a tag or branch name followed by |
| 202 | a colon and then a timestamp. The combination means to take the most |
| 203 | recent check-in with the given tag or branch which is not more recent than |
| 204 | the timestamp. So, for example: |
| @@ -200,11 +209,11 @@ | |
| 209 | |
| 210 | Would cause Fossil to update the working check-out to be the most recent |
| 211 | check-in on the trunk that is not more recent that 14:30 (UTC) on |
| 212 | July 1, 2010. |
| 213 | |
| 214 | <h2 id="root">Root Of A Branch</h2> |
| 215 | |
| 216 | A branch name that begins with the "<tt>root:</tt>" prefix refers to the |
| 217 | last check-in in the parent branch prior to the beginning of the branch. |
| 218 | Such a label is useful, for example, in computing all diffs for a single |
| 219 | branch. The following example will show all changes in the hypothetical |
| @@ -212,35 +221,48 @@ | |
| 221 | |
| 222 | <blockquote> |
| 223 | fossil diff --from root:xyzzy --to xyzzy |
| 224 | </blockquote> |
| 225 | |
| 226 | <a id="merge-in"></a> |
| 227 | A branch name that begins with the "<tt>merge-in:</tt>" prefix refers not |
| 228 | to the root of the branch, but to the most recent merge-in for that branch |
| 229 | from its parent. The most recent merge-in is the version to diff the branch |
| 230 | against in order to see all changes in just the branch itself, omitting |
| 231 | any changes that have already been merged in from the parent branch. |
| 232 | |
| 233 | |
| 234 | <h2 id="special">Special Tags</h2> |
| 235 | |
| 236 | The tag "tip" means the most recent check-in. The "tip" tag is roughly |
| 237 | equivalent to the timestamp tag "5000-01-01". |
| 238 | |
| 239 | This special name works anywhere you can pass a "NAME", such as in in |
| 240 | <tt>/info</tt> URLs: |
| 241 | |
| 242 | <blockquote><pre> |
| 243 | http://localhost:8080/info/tip |
| 244 | </pre></blockquote> |
| 245 | |
| 246 | There are several other special names, but they only work from within a |
| 247 | check-out directory because they are relative to the current checked-out |
| 248 | version: |
| 249 | |
| 250 | * "current": the current checked-out version |
| 251 | * "next": the youngest child of the current checked-out version |
| 252 | * "previous" or "prev": the primary (non-merge) parent of "current" |
| 253 | |
| 254 | Therefore, you can use these names in a <tt>fossil info</tt> command, |
| 255 | but not in an <tt>/info</tt> URL, for example. |
| 256 | |
| 257 | For embedded documentation URLs only, there is one more special name, |
| 258 | "ckout". See [./embeddeddoc.wiki#ckout | its coverage elsewhere] for |
| 259 | more details. You cannot currently use "ckout" anywhere other than in |
| 260 | <tt>/doc</tt> URLs. |
| 261 | |
| 262 | |
| 263 | <h2 id="examples">Additional Examples</h2> |
| 264 | |
| 265 | To view the changes in the most recent check-in prior to the version currently |
| 266 | checked out: |
| 267 | |
| 268 | <blockquote><pre> |
| @@ -251,5 +273,23 @@ | |
| 273 | Then to see everything that has changed on the trunk since the last release: |
| 274 | |
| 275 | <blockquote><pre> |
| 276 | fossil diff --from release --to trunk |
| 277 | </pre></blockquote> |
| 278 | |
| 279 | |
| 280 | <h2 id="order">Resolution Order</h2> |
| 281 | |
| 282 | Fossil currently resolves name strings to artifact hashes in the |
| 283 | following order: |
| 284 | |
| 285 | # Exact matches on [#special | the special names] |
| 286 | # [#timestamps | Timestamps], with preference to ISO8601 forms |
| 287 | # [#tagpfx | tag:TAGNAME] |
| 288 | # [#root | root:BRANCH] |
| 289 | # [#merge-in | merge-in:BRANCH] |
| 290 | # [#tag-ts | TAG:timestamp] |
| 291 | # Full artifact hash or hash prefix. |
| 292 | # Any other type of symbolic name that Fossil extracts from |
| 293 | blockchain artifacts. |
| 294 | |
| 295 | <div style="height:40em" id="this-space-intentionally-left-blank"></div> |
| 296 |