|
1
|
# Glossary |
|
2
|
|
|
3
|
There are several terms-of-art in Fossil that have specific meanings |
|
4
|
which are either not immediately obvious to an outsider or which have |
|
5
|
technical associations that can lead someone to either use the terms |
|
6
|
incorrectly or to get the wrong idea from someone using those terms |
|
7
|
correctly. We hope to teach users how to properly “speak Fossil” with |
|
8
|
this glossary. |
|
9
|
|
|
10
|
The bullet-point lists following each definition are meant to be |
|
11
|
clarifying and illustrative. They are not part of the definitions |
|
12
|
themselves. |
|
13
|
|
|
14
|
|
|
15
|
## <a id="project"></a>Project |
|
16
|
|
|
17
|
A collection of one or more computer files that serve some conceptually |
|
18
|
unified purpose, which purpose changes and evolves over time, with the |
|
19
|
history of that project being a valuable record. |
|
20
|
|
|
21
|
* We qualify the Fossil definition of this common word like this to |
|
22
|
set aside cases where a zip file or tarball would suffice. If you |
|
23
|
can pack your project up into such an archive once and be done with |
|
24
|
it, Fossil is overkill. |
|
25
|
|
|
26
|
And yet that is often just the beginning, since there is often a |
|
27
|
need for something to be changed, so now you have “version 2” of the |
|
28
|
archive file. If you can foresee yourself creating versioned archive |
|
29
|
files for your project, then you probably should be using Fossil for |
|
30
|
it instead, then using Fossil’s [zip] or [tarball] command to |
|
31
|
automatically produce archives of the latest version rather than |
|
32
|
manually produce and track versions of the archive. The web version |
|
33
|
of these commands ([`/zip`][zw] and [`/tarball`][tw]) are |
|
34
|
particularly useful for public distribution of the latest version of |
|
35
|
a project’s files. |
|
36
|
|
|
37
|
* Fossil was designed to host the SQLite software project, which is |
|
38
|
comprised of source code, makefiles, scripts, documentation files, |
|
39
|
and so forth. Fossil is also useful for many other purposes, such as |
|
40
|
a fiction book project where each chapter is held in a separate file |
|
41
|
and assembled into a finished whole deliverable. |
|
42
|
|
|
43
|
* We speak of projects being more than one file because even though |
|
44
|
Fossil can be made to track the history of a single file, it is far |
|
45
|
more often the case that when you get to something of a scale |
|
46
|
sufficient to be called a “project,” there is more than one |
|
47
|
version-tracked file involved, if not at the start, then certainly |
|
48
|
by the end of the project. |
|
49
|
|
|
50
|
To take the example of a fiction book above, instead of putting each |
|
51
|
chapter in a separate file, you could use a single AsciiDoc file for |
|
52
|
the entire book project rather than make use of its [include |
|
53
|
facility][AIF] to assemble it from chapter files, since that does at |
|
54
|
least solve the [key problems][IFRS] inherent in version-tracking |
|
55
|
something like Word’s DOCX format with Fossil instead. |
|
56
|
|
|
57
|
While Fossil will happily track the single file containing the prose |
|
58
|
of your book project for you, you’re still likely to want separate |
|
59
|
files for the cover artwork, a style sheet for use in converting the |
|
60
|
source document to HTML, scripts to convert that intermediate output |
|
61
|
to PDF and ePub in a reliably repeatable fashion, a `README` file |
|
62
|
containing instructions to the printing house, and so forth. |
|
63
|
|
|
64
|
* Fossil requires that all the files for a project be collected into a |
|
65
|
single directory hierarchy, owned by a single user with full rights |
|
66
|
to modify those files. Fossil is not a good choice for managing a |
|
67
|
project that has files scattered hither and yon all over the file |
|
68
|
system, nor of collections of files with complicated ownership and |
|
69
|
access rights. |
|
70
|
|
|
71
|
A project made of an operating system |
|
72
|
installation’s configuration file set is not a good use of Fossil, |
|
73
|
because you’ll have all of your OS’s *other* files intermixed. |
|
74
|
Worse, Fossil doesn’t track OS permissions, so even if you were to |
|
75
|
try to use Fossil as a system deployment tool by archiving versions |
|
76
|
of the OS configuration files and then unpacking them on a new |
|
77
|
system, the extracted project files would have read/write access by |
|
78
|
the user who did the extraction, which probably isn’t what you were |
|
79
|
wanting. |
|
80
|
|
|
81
|
Even with these problems aside, do you really want a `.fslckout` |
|
82
|
SQLite database at the root of your filesystem? Are you prepared for |
|
83
|
the consequences of saying `fossil clean --verily` on such a system? |
|
84
|
You can constrain that with [the `ignore-glob` setting][IGS], but |
|
85
|
are you prepared to write and maintain all the rules needed to keep |
|
86
|
Fossil from blowing away the untracked portions of the file system? |
|
87
|
We believe Fossil is a poor choice for a whole-system configuration |
|
88
|
backup utility. |
|
89
|
|
|
90
|
As a counterexample, a project tracking your [Vim] configuration |
|
91
|
history is a much better use of Fossil, because it’s all held within |
|
92
|
`~/.vim`, and your user has full rights to that subdirectory. |
|
93
|
|
|
94
|
[AIF]: https://docs.asciidoctor.org/asciidoc/latest/directives/include/ |
|
95
|
[IGS]: /help/ignore-glob |
|
96
|
[IFRS]: ./image-format-vs-repo-size.md |
|
97
|
[tarball]: /help/tarball |
|
98
|
[tw]: /help/www/tarball |
|
99
|
[Vim]: https://www.vim.org/ |
|
100
|
[zip]: /help/zip |
|
101
|
[zw]: /help/www/zip |
|
102
|
|
|
103
|
|
|
104
|
## Repository <a id="repository" name="repo"></a> |
|
105
|
|
|
106
|
A single file that contains all historical versions of all files in a |
|
107
|
project, which can be [cloned] to other machines and |
|
108
|
[synchronized][sync] with them. Jargon: repo. |
|
109
|
|
|
110
|
* A Fossil repo is similar to an archive file in that it is a single |
|
111
|
file that stores compressed versions of one or more files. Files can be |
|
112
|
extracted from the repo, and new files can be added to the repo, |
|
113
|
but a Fossil repo has other capabilities |
|
114
|
above and beyond what simple archive formats can do. |
|
115
|
|
|
116
|
* Fossil does not care what you name your repository files, though |
|
117
|
we do suggest “`.fossil`” as a standard extension. There is |
|
118
|
only one place in Fossil where that convention is required, being the |
|
119
|
[`fossil server DIRECTORY`][svrcmd] command, since it serves up |
|
120
|
`*.fossil` files from `DIRECTORY`. If you don’t use that feature, |
|
121
|
you can name your repo files anything you like. |
|
122
|
|
|
123
|
* Cloned and synced repos redundantly store all available information |
|
124
|
about that project, so if any one repo is lost, all of the cloned |
|
125
|
historical content of the project as of the last sync is preserved |
|
126
|
in each surviving repo. |
|
127
|
|
|
128
|
Each user generally clones the project repository down to each |
|
129
|
computer they use to participate in that project, and there is |
|
130
|
usually at least one central host for the project as well, so there |
|
131
|
is usually plenty of redundancy in any given Fossil-based project. |
|
132
|
|
|
133
|
That said, a Fossil repository clone is a backup only in a limited |
|
134
|
sense, because some information can’t be cloned, some doesn’t sync |
|
135
|
by default, and some data is neither clonable nor syncable. We cover |
|
136
|
these limitations and the workarounds for them in a separate |
|
137
|
document, [Backing Up a Remote Fossil Repository][backup]. |
|
138
|
|
|
139
|
* Rather than be a backup, a Fossil repository clone is a |
|
140
|
communication method for coordinating work on the project among |
|
141
|
multiple machines and users: local work done against one repository |
|
142
|
is communicated up to its parent repository on the next sync, and |
|
143
|
work done on other repositories that were previously synced up to |
|
144
|
that parent get pulled down into the local repo clone. |
|
145
|
|
|
146
|
This bidirectional sync is automatic and on by default in Fossil. |
|
147
|
You can [disable it][asdis], or you can [push] or [pull] |
|
148
|
unidirectionally, if you wish. |
|
149
|
|
|
150
|
The Fossil philosophy is that all project information resides in |
|
151
|
each clone of the repository. In the ideal world, this would occur |
|
152
|
instantly and automatically, but in actual use, Fossil falls |
|
153
|
somewhat short of that mark. Some limitations are simply |
|
154
|
technological: a given clone may be temporarily out of communication |
|
155
|
with its parent repository, network delays exist, and so forth. |
|
156
|
Fossil is [an AP mode system][CAP]. (This is sometimes called |
|
157
|
“eventual consistency.”) Other cases come down to administrative |
|
158
|
necessity, as covered in [the backup doc][backup]. |
|
159
|
|
|
160
|
* Fossil doesn’t require that you have redundant clones. Whether you |
|
161
|
do or not is a local decision based on usage needs, communication |
|
162
|
requirements, desire for backups, and so forth. |
|
163
|
|
|
164
|
* Fossil doesn’t care where the repositories are stored, but we |
|
165
|
recommend keeping them all in a single subdirectory such as |
|
166
|
"`~/fossils`" or "`%USERPROFILE%\Fossils`". A flat set of files |
|
167
|
suffices for simple purposes, but you may have use for something |
|
168
|
more complicated. This author uses a scheme like the following on |
|
169
|
mobile machines that shuttle between home and the office: |
|
170
|
|
|
171
|
``` pikchr toggle indent |
|
172
|
box "~/museum/" fit |
|
173
|
move right 0.1 |
|
174
|
line right dotted |
|
175
|
move right 0.05 |
|
176
|
box invis "where one stores valuable fossils" ljust |
|
177
|
|
|
178
|
arrow down 50% from first box.s then right 50% |
|
179
|
box "work/" fit |
|
180
|
move right 0.1 |
|
181
|
line dotted |
|
182
|
move right 0.05 |
|
183
|
box invis "projects from $DAYJOB" ljust |
|
184
|
|
|
185
|
arrow down 50% from 2nd vertex of previous arrow then right 50% |
|
186
|
box "home/" fit |
|
187
|
move right 0.1 |
|
188
|
line dotted right until even with previous line.end |
|
189
|
move right 0.05 |
|
190
|
box invis "personal at-home projects" ljust |
|
191
|
|
|
192
|
arrow down 50% from 2nd vertex of previous arrow then right 50% |
|
193
|
box "other/" fit |
|
194
|
move right 0.1 |
|
195
|
line dotted right until even with previous line.end |
|
196
|
move right 0.05 |
|
197
|
box invis "clones of Fossil itself, SQLite, etc." ljust |
|
198
|
``` |
|
199
|
|
|
200
|
[asdis]: /help/autosync |
|
201
|
[backup]: ./backup.md |
|
202
|
[CAP]: ./cap-theorem.md |
|
203
|
[cloned]: /help/clone |
|
204
|
[pull]: /help/pull |
|
205
|
[push]: /help/push |
|
206
|
[svrcmd]: /help/server |
|
207
|
[sync]: /help/sync |
|
208
|
|
|
209
|
[repository]: #repo |
|
210
|
[repositories]: #repo |
|
211
|
|
|
212
|
|
|
213
|
## Version / Revision / Hash / UUID <a id="version" name="hash"></a> |
|
214
|
|
|
215
|
These terms all mean the same thing: a long hexadecimal |
|
216
|
[SHA hash value](./hashes.md) that uniquely identifies a particular |
|
217
|
[check-in](#ci). |
|
218
|
|
|
219
|
We’ve listed the alternatives in decreasing preference order: |
|
220
|
|
|
221
|
* **Version** and **revision** are near-synonyms in common usage. |
|
222
|
Fossil’s code and documentation use both interchangeably because |
|
223
|
Fossil was created to manage the development of the SQLite project, |
|
224
|
which formerly used [CVS], the Concurrent Versions System. CVS in |
|
225
|
turn started out as a front-end to [RCS], the Revision Control |
|
226
|
System, but even though CVS uses “version” in its name, it numbers |
|
227
|
check-ins using a system derived from RCS’s scheme, which it calls |
|
228
|
“Revisions” in user-facing output. Fossil inherits this confusion |
|
229
|
honestly. |
|
230
|
|
|
231
|
* **Hash** refers to the [SHA1 or SHA3-256 hash](./hashes.md) of the |
|
232
|
content of the checked-in data, uniquely identifying that version of |
|
233
|
the managed files. It is a strictly correct synonym, used more often |
|
234
|
in low-level contexts than the term “version.” |
|
235
|
|
|
236
|
* **UUID** is a deprecated term still found in many parts of the |
|
237
|
Fossil internals and (decreasingly) its documentation. The problem |
|
238
|
with using this as a synonym for a Fossil-managed version of the |
|
239
|
managed files is that there are [standards][UUID] defining the |
|
240
|
format of a “UUID,” none of which Fossil follows, not even the |
|
241
|
[version 4][ruuid] (random) format, the type of UUID closest in |
|
242
|
meaning and usage to a Fossil hash.(^A pre-Fossil 2.0 style SHA1 |
|
243
|
hash is 160 bits, not the 128 bits many people expect for a proper |
|
244
|
UUID, and even if you truncate it to 128 bits to create a “good |
|
245
|
enough” version prefix, the 6 bits reserved in the UUID format for |
|
246
|
the variant code cannot make a correct declaration except by a |
|
247
|
random 1:64 chance. The SHA3-256 option allowed in Fossil 2.0 and |
|
248
|
higher doesn’t help with this confusion, making a Fossil version |
|
249
|
hash twice as large as a proper UUID. Alas, the term will never be |
|
250
|
fully obliterated from use since there are columns in the Fossil |
|
251
|
repository format that use the obsolete term; we cannot change this |
|
252
|
without breaking backwards compatibility.) |
|
253
|
|
|
254
|
You will find all of these synonyms used in the Fossil documentation. |
|
255
|
Some day we may settle on a single term, but it doesn’t seem likely. |
|
256
|
|
|
257
|
[CVS]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
|
258
|
[hash]: #version |
|
259
|
[RCS]: https://en.wikipedia.org/wiki/Revision_Control_System |
|
260
|
[ruuid]: https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) |
|
261
|
[snfs]: https://en.wikipedia.org/wiki/Snapshot_(computer_storage)#File_systems |
|
262
|
[UUID]: https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) |
|
263
|
[version]: #version |
|
264
|
|
|
265
|
|
|
266
|
## Check-in <a id="check-in" name="ci"></a> |
|
267
|
|
|
268
|
A [version] of the project’s files that have been committed to the |
|
269
|
[repository]; as such, it is sometimes called a “commit” instead. A |
|
270
|
check-in is a snapshot of the project at an instant in time, as seen from |
|
271
|
a single [check-out’s](#co) perspective. It is sometimes styled |
|
272
|
“`CHECKIN`”, especially in command documentation where any |
|
273
|
[valid check-in name][ciname] can be used. |
|
274
|
|
|
275
|
* There is a harmless conflation of terms here: any of the various |
|
276
|
synonyms for [version] may be used where “check-in” is more accurate, |
|
277
|
and vice versa, because there is a 1:1 relation between them. A |
|
278
|
check-in *has* a version, but a version suffices to uniquely look up |
|
279
|
a particular commit.[^snapshot] |
|
280
|
|
|
281
|
* Combining both sets of synonyms results in a list of terms that is |
|
282
|
confusing to new Fossil users, but it’s easy |
|
283
|
enough to internalize the concepts. [Committing][commit] creates a |
|
284
|
*commit.* It may also be said to create a checked-in *version* of a |
|
285
|
particular *revision* of the project’s files, thus creating an |
|
286
|
immutable *snapshot* of the project’s state at the time of the |
|
287
|
commit. Fossil users find each of these different words for the |
|
288
|
same concept useful for expressive purposes among ourselves, but to |
|
289
|
Fossil proper, they all mean the same thing. |
|
290
|
|
|
291
|
* Check-ins are immutable. |
|
292
|
|
|
293
|
* Check-ins exist only inside the repository. Contrast a |
|
294
|
[check-out](#co). |
|
295
|
|
|
296
|
* Check-ins may have [one or more names][ciname], but only the |
|
297
|
[hash] is globally unique, across all time; we call it the check-in’s |
|
298
|
canonical name. The other names are either imprecise, contextual, or |
|
299
|
change their meaning over time and across [repositories]. |
|
300
|
|
|
301
|
[^snapshot]: You may sometimes see the term “snapshot” used as a synonym |
|
302
|
for a check-in or the version number identifying said check-in. We |
|
303
|
must warn against this usage because there is a potential confusion |
|
304
|
here: [the `stash` command][stash] uses the term “snapshot,” as does |
|
305
|
[the `undo` system][undo] to make a distinction with check-ins. |
|
306
|
Nevertheless, there is a conceptual overlap here between Fossil and |
|
307
|
systems that do use the term “snapshot,” the primary distinction being |
|
308
|
that Fossil will capture only changes to files you’ve [added][add] to |
|
309
|
the [repository], not to everything in [the check-out directory](#co) |
|
310
|
at the time of the snapshot. (Thus [the `extras` command][extras].) |
|
311
|
Contrast a snapshot taken by a virtual machine system or a |
|
312
|
[snapshotting file system][snfs], which captures changes to everything |
|
313
|
on the managed storage volume. |
|
314
|
|
|
315
|
[add]: /help/add |
|
316
|
[ciname]: ./checkin_names.wiki |
|
317
|
[extras]: /help/extras |
|
318
|
[stash]: /help/stash |
|
319
|
[undo]: /help/undo |
|
320
|
|
|
321
|
|
|
322
|
|
|
323
|
## Check-out <a id="check-out" name="co"></a> |
|
324
|
|
|
325
|
A set of files extracted from a [repository] that represent a |
|
326
|
particular [check-in](#ci) of the [project](#project). |
|
327
|
|
|
328
|
* Unlike a check-in, a check-out is mutable. It may start out as a |
|
329
|
version of a particular check-in extracted from the repository, but |
|
330
|
the user is then free to make modifications to the checked-out |
|
331
|
files. Once those changes are formally [committed][commit], they |
|
332
|
become a new immutable check-in, derived from its parent check-in. |
|
333
|
|
|
334
|
* You can switch from one check-in to another within a check-out |
|
335
|
directory by passing those names to [the `fossil update` |
|
336
|
command][update]. |
|
337
|
|
|
338
|
* Check-outs relate to repositories in a one-to-many fashion: it is |
|
339
|
common to have a single repo clone on a machine but to have it |
|
340
|
[open] in [multiple working directories][mwd]. Check-out directories |
|
341
|
are associated with the repos they were created from by settings |
|
342
|
stored in the check-out directory. This is in the `.fslckout` file on |
|
343
|
POSIX type systems, but for historical compatibility reasons, it’s |
|
344
|
called `_FOSSIL_` by native Windows builds of Fossil. |
|
345
|
|
|
346
|
(Contrast the Cygwin and WSL Fossil binaries, which use POSIX file |
|
347
|
naming rules.) |
|
348
|
|
|
349
|
* In the same way that one cannot extract files from a zip archive |
|
350
|
without having a copy of that zip file, one cannot make check-outs |
|
351
|
without access to the repository file or a clone thereof. |
|
352
|
|
|
353
|
* Because a Fossil repository is an SQLite database file, the same |
|
354
|
rules for avoiding data corruption apply to it. In particular, it is |
|
355
|
[nearly a hard requirement][h2cflp] that the repository clone be on |
|
356
|
the same machine as the one where you make check-outs and the |
|
357
|
subsequent check-ins. |
|
358
|
|
|
359
|
That said, the relative locations of the repo and the check-out |
|
360
|
within the local file system are arbitrary. The repository may be |
|
361
|
located inside the folder holding the check-out, but it certainly |
|
362
|
does not have to be, and it usually is not. As an example, [the |
|
363
|
Fossil plugin for Visual Studio Code][fpvsc] defaults to storing the |
|
364
|
repo clone within the project directory as a file called `.fsl`, but |
|
365
|
this is because VSCode’s version control features assume it’s being |
|
366
|
used with Git, where the repository is the `.git` subdirectory |
|
367
|
contents. With Fossil, [different check-out workflows][cwork] are |
|
368
|
preferred. |
|
369
|
|
|
370
|
[commit]: /help/commit |
|
371
|
[cwork]: ./ckout-workflows.md |
|
372
|
[h2cflp]: https://www.sqlite.org/howtocorrupt.html#_file_locking_problems |
|
373
|
[fpvsc]: https://marketplace.visualstudio.com/items?itemName=koog1000.fossil |
|
374
|
[open]: /help/open |
|
375
|
[mwd]: ./ckout-workflows.md#mcw |
|
376
|
[update]: /help/update |
|
377
|
|
|
378
|
|
|
379
|
## <a id="docs"></a>Embedded Documentation |
|
380
|
|
|
381
|
Serving as an alternative to Fossil’s built-in [wiki], the [embedded |
|
382
|
documentation feature][edoc] stores the same type of marked-up text |
|
383
|
files, but under Fossil’s powerful version control features. |
|
384
|
|
|
385
|
* The simple rule for determining whether to use the wiki or embedded |
|
386
|
docs for any given document is whether the content is considered |
|
387
|
“evergreen,” as with a Wikipedia article. |
|
388
|
|
|
389
|
While Fossil’s wiki feature does store the history of each |
|
390
|
document’s changes, Fossil always presents the current version of |
|
391
|
the document unless you manually go out of your way to dig back into |
|
392
|
the history. Then, having done so, links from that historical |
|
393
|
version of the wiki document take you to the current versions of the |
|
394
|
target documents, not to the version contemporaneous with the source |
|
395
|
document. |
|
396
|
|
|
397
|
The consequence is that if you say something like… |
|
398
|
|
|
399
|
$ fossil up 2020-04-01 |
|
400
|
$ fossil ui --page wcontent |
|
401
|
|
|
402
|
…you will **not** see the list of wiki articles as of April Fool’s Day in 2020, but |
|
403
|
instead the list of *current* wiki article versions, the same as if you ran it |
|
404
|
from a check-out of the tip-of-trunk. |
|
405
|
|
|
406
|
Contrast embedded docs, which are not only version-controlled as |
|
407
|
normal files are in Fossil, they participate in all the tagging, |
|
408
|
branching, and other versioning features. There are several |
|
409
|
consequences of this, such as that Fossil’s [special check-in |
|
410
|
names][ciname] work with embedded doc URLs: |
|
411
|
|
|
412
|
* <p>If you visit an embedded doc as `/doc/release/file.md` and |
|
413
|
then click on a relative link from that document, you will remain on |
|
414
|
the release branch. This lets you see not only the release |
|
415
|
version of a software project but also the documentation as of |
|
416
|
that release.</p> |
|
417
|
|
|
418
|
* <p>If you visit `/doc/2020-04-01/file.md`, you will not only |
|
419
|
pull up the version of `file.md` as of that date, relative links |
|
420
|
will take you to contemporaneous versions of those embedded docs |
|
421
|
as well.</p> |
|
422
|
|
|
423
|
* <p>If you say `fossil up 2020-04-01 && fossil ui` and then visit |
|
424
|
`/doc/ckout/file.md`, you’ll not only see the checked-out |
|
425
|
version of the file as of that date, relative links will show |
|
426
|
you other files within that checkout.</p> |
|
427
|
|
|
428
|
* Fossil’s wiki presents a flat list of articles, while embedded docs |
|
429
|
are stored in the repository’s file hierarchy, a powerful |
|
430
|
organizational tool well-suited to complicated documentation. |
|
431
|
|
|
432
|
* Your repository’s Home page is a good candidate for the wiki, as is |
|
433
|
documentation meant for use only with the current version of the |
|
434
|
repository’s contents. |
|
435
|
|
|
436
|
* If you are at all uncertain whether to use the wiki or the embedded |
|
437
|
documentation feature, prefer the latter, since it is inherently |
|
438
|
more powerful, and when you use the [`/fileedit` feature][fef], the |
|
439
|
workflow is scarcely different from using the wiki. |
|
440
|
|
|
441
|
(This very file is embedded documentation: clone |
|
442
|
[Fossil’s self-hosting repository][fshr] and you will find it as |
|
443
|
`www/glossary.md`.) |
|
444
|
|
|
445
|
[edoc]: ./embeddeddoc.wiki |
|
446
|
[fef]: ./fileedit-page.md |
|
447
|
[fshr]: ./selfhost.wiki |
|
448
|
[wiki]: ./wikitheory.wiki |
|
449
|
|
|
450
|
|
|
451
|
## <a id="cap"></a>Capability |
|
452
|
|
|
453
|
Fossil includes a powerful [role-based access control system][rbac] |
|
454
|
which affects which users have permission to do certain things within a given |
|
455
|
[repository]. You can read more about this complex topic |
|
456
|
[here](./caps/). |
|
457
|
|
|
458
|
Some people — and indeed certain parts of Fossil’s own code — use the |
|
459
|
term “permissions” instead, but since [operating system file permissions |
|
460
|
also play into this](./caps/#webonly), we prefer the term “capabilities” |
|
461
|
(or “caps” for short) when talking about Fossil’s RBAC system to avoid a |
|
462
|
confusion here. |
|
463
|
|
|
464
|
[rbac]: https://en.wikipedia.org/wiki/Role-based_access_control |
|
465
|
|
|
466
|
<div style="height:50em" id="this-space-intentionally-left-blank"></div> |
|
467
|
|