Fossil SCM

Soften the introduction to the "backup.md" documentation page, so that beginners do not get the impression that backups are critical for successful Fossil deployments.

drh 2020-10-13 00:40 trunk
Commit c14a1f6001d9554972d70eba3cc36c725b379119a05488298030b81e66ae227c
1 file changed +18 -11
+18 -11
--- www/backup.md
+++ www/backup.md
@@ -1,16 +1,22 @@
11
# Backing Up a Remote Fossil Repository
22
3
-Simply cloning a Fossil repository does not necessarily create a
4
-*complete* backup of the remote repository’s contents. With an existing
5
-clone, Fossil’s autosync feature isn’t enough to keep that clone fully
6
-up-to-date in a backup failover sense. This document explains what your
7
-clone may be missing and how to ensure that it is complete for cases
8
-where you wish to have a backup suitable for replacing it without data
9
-loss, should the need arise.
10
-
11
-
3
+One of the great benefits of Fossil and other [distributed version control systems][dvcs]
4
+is that cloning a repository makes a backup. So if you are running a project with multiple
5
+developers who share their work using a [central server][server] and the server hardware
6
+catches fire or otherwise becomes unavailable, the clones of the repository on each developer
7
+workstation serve as a suitable backup.
8
+
9
+[dvcs]: wikipedia:/wiki/Distributed_version_control
10
+[server]: ./server/whyuseaserver.wiki
11
+
12
+Mostly.
13
+
14
+It turns out not everything in a Fossil repository is copied via clone. A clone
15
+protects all of the checked in code. But a Fossil repository typically contains
16
+other useful information that is not always shared as part of a clone, and might need
17
+to be backed up separately. To wit:
1218
1319
## Sensitive Information
1420
1521
Fossil purposefully does not clone certain sensitive information unless
1622
you’re logged in with [setup] capability. As an example, a local clone
@@ -23,12 +29,13 @@
2329
2430
Fossil allows the local configuration in certain areas to differ from
2531
that of the remote. With the exception of the prior item, you get a copy
2632
of these configuration areas on initial clone, but after that, some
2733
remote configuration changes don’t sync down automatically, such as the
28
-remote’s skin. You have to ask for updates to these configuration areas
29
-explicitly.
34
+remote’s skin. You can ask for updates by running the
35
+[`fossil config pull skiin`](./help?cmd=config) if you want, but that
36
+does not happen automatically during the course of normal development.
3037
3138
3239
## Private Branches
3340
3441
The very nature of Fossil’s [private branch feature][pbr] ensures that
3542
--- www/backup.md
+++ www/backup.md
@@ -1,16 +1,22 @@
1 # Backing Up a Remote Fossil Repository
2
3 Simply cloning a Fossil repository does not necessarily create a
4 *complete* backup of the remote repository’s contents. With an existing
5 clone, Fossil’s autosync feature isn’t enough to keep that clone fully
6 up-to-date in a backup failover sense. This document explains what your
7 clone may be missing and how to ensure that it is complete for cases
8 where you wish to have a backup suitable for replacing it without data
9 loss, should the need arise.
10
11
 
 
 
 
 
 
12
13 ## Sensitive Information
14
15 Fossil purposefully does not clone certain sensitive information unless
16 you’re logged in with [setup] capability. As an example, a local clone
@@ -23,12 +29,13 @@
23
24 Fossil allows the local configuration in certain areas to differ from
25 that of the remote. With the exception of the prior item, you get a copy
26 of these configuration areas on initial clone, but after that, some
27 remote configuration changes don’t sync down automatically, such as the
28 remote’s skin. You have to ask for updates to these configuration areas
29 explicitly.
 
30
31
32 ## Private Branches
33
34 The very nature of Fossil’s [private branch feature][pbr] ensures that
35
--- www/backup.md
+++ www/backup.md
@@ -1,16 +1,22 @@
1 # Backing Up a Remote Fossil Repository
2
3 One of the great benefits of Fossil and other [distributed version control systems][dvcs]
4 is that cloning a repository makes a backup. So if you are running a project with multiple
5 developers who share their work using a [central server][server] and the server hardware
6 catches fire or otherwise becomes unavailable, the clones of the repository on each developer
7 workstation serve as a suitable backup.
8
9 [dvcs]: wikipedia:/wiki/Distributed_version_control
10 [server]: ./server/whyuseaserver.wiki
11
12 Mostly.
13
14 It turns out not everything in a Fossil repository is copied via clone. A clone
15 protects all of the checked in code. But a Fossil repository typically contains
16 other useful information that is not always shared as part of a clone, and might need
17 to be backed up separately. To wit:
18
19 ## Sensitive Information
20
21 Fossil purposefully does not clone certain sensitive information unless
22 you’re logged in with [setup] capability. As an example, a local clone
@@ -23,12 +29,13 @@
29
30 Fossil allows the local configuration in certain areas to differ from
31 that of the remote. With the exception of the prior item, you get a copy
32 of these configuration areas on initial clone, but after that, some
33 remote configuration changes don’t sync down automatically, such as the
34 remote’s skin. You can ask for updates by running the
35 [`fossil config pull skiin`](./help?cmd=config) if you want, but that
36 does not happen automatically during the course of normal development.
37
38
39 ## Private Branches
40
41 The very nature of Fossil’s [private branch feature][pbr] ensures that
42

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button