Fossil SCM
Reworked the "Clones and Backups" section of www/caps/admin-v-setup.md now that we have www/backup.md.
Commit
dd65d143c3d6787e1a24a1cc679dd6e5cc9135656a83b66c822b50d22c976faf
Parent
8813ae91a699ac7…
1 file changed
+14
-14
+14
-14
| --- www/caps/admin-v-setup.md | ||
| +++ www/caps/admin-v-setup.md | ||
| @@ -1,6 +1,6 @@ | ||
| 1 | -# Differences Between Setup and Admin User | |
| 1 | +# Differences Between Setup and Admin Users | |
| 2 | 2 | |
| 3 | 3 | This document explains the distinction between [Setup users][caps] and |
| 4 | 4 | [Admin users][capa]. For other information about use types, see: |
| 5 | 5 | |
| 6 | 6 | * [Administering User Capabilities](./) |
| @@ -229,27 +229,27 @@ | ||
| 229 | 229 | user with these powers, you should not grant that user Admin capability. |
| 230 | 230 | |
| 231 | 231 | |
| 232 | 232 | ## <a name="clones"></a>Clones and Backups |
| 233 | 233 | |
| 234 | -Keep in mind that Fossil is a *distributed* version control system, | |
| 235 | -which means that a user known to Fossil might have Setup capability on | |
| 236 | -one repository but be a mere "user" on one of its clones. The most | |
| 237 | -common case is that when you clone a repository, even anonymously, you | |
| 238 | -gain Setup power over the local clone. | |
| 234 | +Fossil is a *distributed* version control system, which has direct | |
| 235 | +effects on the “Setup user” concept in the face of clones. When you | |
| 236 | +clone a repository, your local user becomes a Setup user on the local | |
| 237 | +clone even if you are not one on the remote repository. This may be | |
| 238 | +surprising to you, but it should also be sensible once you realize that | |
| 239 | +your operating system will generally give you full control over the | |
| 240 | +local repository file. What use trying to apply remote restrictions on | |
| 241 | +the local file, then? | |
| 239 | 242 | |
| 240 | 243 | The distinctions above therefore are intransitive: they apply only |
| 241 | 244 | within a single repository instance. |
| 242 | 245 | |
| 243 | -The exception to this is when the clone is done as a Setup user, since | |
| 244 | -this also copies the `user` table on the initial clone. A user with | |
| 245 | -Setup capability can subsequently say [`fossil conf pull all`][fcp] to | |
| 246 | -update that table and everything else not normally synchronized between | |
| 247 | -Fossil repositories. In this way, a Setup user can create multiple | |
| 248 | -interchangeable clones. This is useful not only to guard against rogue | |
| 249 | -Admin-only users, it is a useful element of a load balancing and | |
| 250 | -failover system. | |
| 246 | +Fossil behaves differently when you do a clone as a user with Setup | |
| 247 | +capability on the remote repository, which primarily has effects on the | |
| 248 | +fidelity of clone-as-backup, which we cover [elsewhere](../backup.md). | |
| 249 | +We strongly encourage you to read that document if you expect to use a | |
| 250 | +clone as a complete replacement for the remote repository. | |
| 251 | 251 | |
| 252 | 252 | |
| 253 | 253 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 254 | 254 | |
| 255 | 255 | Setup users get [every user capability](./ref.html) of Fossil except for |
| 256 | 256 |
| --- www/caps/admin-v-setup.md | |
| +++ www/caps/admin-v-setup.md | |
| @@ -1,6 +1,6 @@ | |
| 1 | # Differences Between Setup and Admin User |
| 2 | |
| 3 | This document explains the distinction between [Setup users][caps] and |
| 4 | [Admin users][capa]. For other information about use types, see: |
| 5 | |
| 6 | * [Administering User Capabilities](./) |
| @@ -229,27 +229,27 @@ | |
| 229 | user with these powers, you should not grant that user Admin capability. |
| 230 | |
| 231 | |
| 232 | ## <a name="clones"></a>Clones and Backups |
| 233 | |
| 234 | Keep in mind that Fossil is a *distributed* version control system, |
| 235 | which means that a user known to Fossil might have Setup capability on |
| 236 | one repository but be a mere "user" on one of its clones. The most |
| 237 | common case is that when you clone a repository, even anonymously, you |
| 238 | gain Setup power over the local clone. |
| 239 | |
| 240 | The distinctions above therefore are intransitive: they apply only |
| 241 | within a single repository instance. |
| 242 | |
| 243 | The exception to this is when the clone is done as a Setup user, since |
| 244 | this also copies the `user` table on the initial clone. A user with |
| 245 | Setup capability can subsequently say [`fossil conf pull all`][fcp] to |
| 246 | update that table and everything else not normally synchronized between |
| 247 | Fossil repositories. In this way, a Setup user can create multiple |
| 248 | interchangeable clones. This is useful not only to guard against rogue |
| 249 | Admin-only users, it is a useful element of a load balancing and |
| 250 | failover system. |
| 251 | |
| 252 | |
| 253 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 254 | |
| 255 | Setup users get [every user capability](./ref.html) of Fossil except for |
| 256 |
| --- www/caps/admin-v-setup.md | |
| +++ www/caps/admin-v-setup.md | |
| @@ -1,6 +1,6 @@ | |
| 1 | # Differences Between Setup and Admin Users |
| 2 | |
| 3 | This document explains the distinction between [Setup users][caps] and |
| 4 | [Admin users][capa]. For other information about use types, see: |
| 5 | |
| 6 | * [Administering User Capabilities](./) |
| @@ -229,27 +229,27 @@ | |
| 229 | user with these powers, you should not grant that user Admin capability. |
| 230 | |
| 231 | |
| 232 | ## <a name="clones"></a>Clones and Backups |
| 233 | |
| 234 | Fossil is a *distributed* version control system, which has direct |
| 235 | effects on the “Setup user” concept in the face of clones. When you |
| 236 | clone a repository, your local user becomes a Setup user on the local |
| 237 | clone even if you are not one on the remote repository. This may be |
| 238 | surprising to you, but it should also be sensible once you realize that |
| 239 | your operating system will generally give you full control over the |
| 240 | local repository file. What use trying to apply remote restrictions on |
| 241 | the local file, then? |
| 242 | |
| 243 | The distinctions above therefore are intransitive: they apply only |
| 244 | within a single repository instance. |
| 245 | |
| 246 | Fossil behaves differently when you do a clone as a user with Setup |
| 247 | capability on the remote repository, which primarily has effects on the |
| 248 | fidelity of clone-as-backup, which we cover [elsewhere](../backup.md). |
| 249 | We strongly encourage you to read that document if you expect to use a |
| 250 | clone as a complete replacement for the remote repository. |
| 251 | |
| 252 | |
| 253 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 254 | |
| 255 | Setup users get [every user capability](./ref.html) of Fossil except for |
| 256 |