Fossil SCM
Moved the section on backups in the Email Alerts doc into the new backup doc, and expanded on the coverage of config backups there, since this splits the prior section.
Commit
2b1c5bc8fe80f701b1876068afd24bb029797ebdc7c63fac43c52cd3811d8390
Parent
6b472ae172549d3…
2 files changed
+1
-12
+46
-9
+1
-12
| --- www/alerts.md | ||
| +++ www/alerts.md | ||
| @@ -530,22 +530,11 @@ | ||
| 530 | 530 | |
| 531 | 531 | |
| 532 | 532 | <a id="backup"></a> |
| 533 | 533 | ## Cloning, Syncing, and Backups |
| 534 | 534 | |
| 535 | -The Admin → Notification settings are not replicated using clone or | |
| 536 | -sync, and it is not possible to push such settings from one repository | |
| 537 | -to another. In a network of peer repositories, you only want one | |
| 538 | -repository sending email alerts. If you were to replicate the email | |
| 539 | -alert settings to a separate repository, then subscribers would get | |
| 540 | -multiple alerts for each event, which would be bad. | |
| 541 | - | |
| 542 | -However, the subscriber list can be synced for backup purposes. Use the | |
| 543 | -[`fossil config pull subscriber`](/help?cmd=configuration) command to | |
| 544 | -pull the latest subscriber list from a server into a backup repository. | |
| 545 | - | |
| 546 | -The `push`, `export`, and `import` commands all work similarly. | |
| 535 | +That’s [covered elsewhere](./backup.md#alerts). | |
| 547 | 536 | |
| 548 | 537 | |
| 549 | 538 | <a id="pages" name="commands"></a> |
| 550 | 539 | ## Controlling the Email Alert System |
| 551 | 540 | |
| 552 | 541 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -530,22 +530,11 @@ | |
| 530 | |
| 531 | |
| 532 | <a id="backup"></a> |
| 533 | ## Cloning, Syncing, and Backups |
| 534 | |
| 535 | The Admin → Notification settings are not replicated using clone or |
| 536 | sync, and it is not possible to push such settings from one repository |
| 537 | to another. In a network of peer repositories, you only want one |
| 538 | repository sending email alerts. If you were to replicate the email |
| 539 | alert settings to a separate repository, then subscribers would get |
| 540 | multiple alerts for each event, which would be bad. |
| 541 | |
| 542 | However, the subscriber list can be synced for backup purposes. Use the |
| 543 | [`fossil config pull subscriber`](/help?cmd=configuration) command to |
| 544 | pull the latest subscriber list from a server into a backup repository. |
| 545 | |
| 546 | The `push`, `export`, and `import` commands all work similarly. |
| 547 | |
| 548 | |
| 549 | <a id="pages" name="commands"></a> |
| 550 | ## Controlling the Email Alert System |
| 551 | |
| 552 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -530,22 +530,11 @@ | |
| 530 | |
| 531 | |
| 532 | <a id="backup"></a> |
| 533 | ## Cloning, Syncing, and Backups |
| 534 | |
| 535 | That’s [covered elsewhere](./backup.md#alerts). |
| 536 | |
| 537 | |
| 538 | <a id="pages" name="commands"></a> |
| 539 | ## Controlling the Email Alert System |
| 540 | |
| 541 |
+46
-9
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -26,17 +26,54 @@ | ||
| 26 | 26 | reasons. |
| 27 | 27 | |
| 28 | 28 | |
| 29 | 29 | ## <a id="config"></a> Configuration Drift |
| 30 | 30 | |
| 31 | -Fossil allows the local configuration in certain areas to differ from | |
| 32 | -that of the remote. With the exception of the prior item, you get a copy | |
| 33 | -of these configuration areas on initial clone, but after that, some | |
| 34 | -remote configuration changes don’t sync down automatically, such as the | |
| 35 | -remote’s skin. You can ask for updates by running the | |
| 36 | -[`fossil config pull skin`](./help?cmd=config) command, but that | |
| 37 | -does not happen automatically during the course of normal development. | |
| 31 | +Fossil allows the local configuration to differ in several areas from | |
| 32 | +that of the remote. You get a copy | |
| 33 | +of *some* of these configuration areas on initial clone — not all! — but after that, | |
| 34 | +remote configuration changes mostly do not sync down automatically. | |
| 35 | + | |
| 36 | + | |
| 37 | +#### <a id="skin"></a> Skin | |
| 38 | + | |
| 39 | +Changes to the remote’s skin don’t sync down, on purpose, since you may | |
| 40 | +want to have a different skin on the local clone than on the remote. You | |
| 41 | +can ask for updates with [`fossil config pull skin`][cfg], but that does | |
| 42 | +not happen automatically during the course of normal development. | |
| 43 | + | |
| 44 | + | |
| 45 | +#### <a id="alerts"></a> Email Alerts | |
| 46 | + | |
| 47 | +The Admin → Notification settings do not get copied on clone or sync, | |
| 48 | +and it is not possible to push such settings from one repository to | |
| 49 | +another. We did this on purpose because you may have a network of peer | |
| 50 | +repositories, and you only want one repository sending email alerts. If | |
| 51 | +Fossil were to automatically replicate the email alert settings to a | |
| 52 | +separate repository, subscribers would get multiple alerts for each | |
| 53 | +event, which would be *bad.* | |
| 54 | + | |
| 55 | +The only element of the email alert configuration that can be pulled | |
| 56 | +over the sync protocol on demand is the subscriber list, via | |
| 57 | +[`fossil config pull subscriber`][cfg]. | |
| 58 | + | |
| 59 | + | |
| 60 | +#### <a id="project"></a> Project Configuration | |
| 61 | + | |
| 62 | +This is normally generated once during `fossil init` and never changed, | |
| 63 | +so Fossil doesn’t pull this information without being forced, on | |
| 64 | +purpose. You could accidentally merge two separate Fossil repos by | |
| 65 | +pushing one repo’s project config up to another, for example. | |
| 66 | + | |
| 67 | + | |
| 68 | +#### <a id="other-cfg"></a> Others | |
| 69 | + | |
| 70 | +A repo’s URL aliases, [interwiki configuration](./interwiki.md), and | |
| 71 | +[ticket customizations](./custom_tcket.wiki) also do not normally sync. | |
| 72 | + | |
| 73 | +[cfg]: /help?cmd=configuration | |
| 74 | + | |
| 38 | 75 | |
| 39 | 76 | |
| 40 | 77 | ## <a id="private"></a> Private Branches |
| 41 | 78 | |
| 42 | 79 | The very nature of Fossil’s [private branch feature][pbr] ensures that |
| @@ -92,11 +129,11 @@ | ||
| 92 | 129 | source of truth, those users still syncing with `svr2` won’t have their |
| 93 | 130 | commits pushed up to `svr1` unless you’ve set up bidirectional sync, |
| 94 | 131 | rather than have the two backup servers do `pull` only. |
| 95 | 132 | |
| 96 | 133 | |
| 97 | -# Solution 1: Explicit Pulls | |
| 134 | +# <a id="sync-solution"></a> Solution 1: Explicit Pulls | |
| 98 | 135 | |
| 99 | 136 | The following script solves most of the above problems for the use case |
| 100 | 137 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 101 | 138 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 102 | 139 | the remote as a user with Setup capability, however. |
| @@ -119,11 +156,11 @@ | ||
| 119 | 156 | that it will continue to have information that the remote says should |
| 120 | 157 | not exist any more. That would be not so much a “backup” as an |
| 121 | 158 | “archive,” which might not be what you want. |
| 122 | 159 | |
| 123 | 160 | |
| 124 | -# Solution 2: SQL-Level Backup | |
| 161 | +# <a id="sql-solution"></a> Solution 2: SQL-Level Backup | |
| 125 | 162 | |
| 126 | 163 | The first method doesn’t get you a copy of the remote’s |
| 127 | 164 | [private branches][pbr], on purpose. It may also miss other info on the |
| 128 | 165 | remote, such as SQL-level customizations that the sync protocol can’t |
| 129 | 166 | see. (Some [ticket system customization][tkt] schemes rely on this ability, for example.) You can |
| 130 | 167 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -26,17 +26,54 @@ | |
| 26 | reasons. |
| 27 | |
| 28 | |
| 29 | ## <a id="config"></a> Configuration Drift |
| 30 | |
| 31 | Fossil allows the local configuration in certain areas to differ from |
| 32 | that of the remote. With the exception of the prior item, you get a copy |
| 33 | of these configuration areas on initial clone, but after that, some |
| 34 | remote configuration changes don’t sync down automatically, such as the |
| 35 | remote’s skin. You can ask for updates by running the |
| 36 | [`fossil config pull skin`](./help?cmd=config) command, but that |
| 37 | does not happen automatically during the course of normal development. |
| 38 | |
| 39 | |
| 40 | ## <a id="private"></a> Private Branches |
| 41 | |
| 42 | The very nature of Fossil’s [private branch feature][pbr] ensures that |
| @@ -92,11 +129,11 @@ | |
| 92 | source of truth, those users still syncing with `svr2` won’t have their |
| 93 | commits pushed up to `svr1` unless you’ve set up bidirectional sync, |
| 94 | rather than have the two backup servers do `pull` only. |
| 95 | |
| 96 | |
| 97 | # Solution 1: Explicit Pulls |
| 98 | |
| 99 | The following script solves most of the above problems for the use case |
| 100 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 101 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 102 | the remote as a user with Setup capability, however. |
| @@ -119,11 +156,11 @@ | |
| 119 | that it will continue to have information that the remote says should |
| 120 | not exist any more. That would be not so much a “backup” as an |
| 121 | “archive,” which might not be what you want. |
| 122 | |
| 123 | |
| 124 | # Solution 2: SQL-Level Backup |
| 125 | |
| 126 | The first method doesn’t get you a copy of the remote’s |
| 127 | [private branches][pbr], on purpose. It may also miss other info on the |
| 128 | remote, such as SQL-level customizations that the sync protocol can’t |
| 129 | see. (Some [ticket system customization][tkt] schemes rely on this ability, for example.) You can |
| 130 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -26,17 +26,54 @@ | |
| 26 | reasons. |
| 27 | |
| 28 | |
| 29 | ## <a id="config"></a> Configuration Drift |
| 30 | |
| 31 | Fossil allows the local configuration to differ in several areas from |
| 32 | that of the remote. You get a copy |
| 33 | of *some* of these configuration areas on initial clone — not all! — but after that, |
| 34 | remote configuration changes mostly do not sync down automatically. |
| 35 | |
| 36 | |
| 37 | #### <a id="skin"></a> Skin |
| 38 | |
| 39 | Changes to the remote’s skin don’t sync down, on purpose, since you may |
| 40 | want to have a different skin on the local clone than on the remote. You |
| 41 | can ask for updates with [`fossil config pull skin`][cfg], but that does |
| 42 | not happen automatically during the course of normal development. |
| 43 | |
| 44 | |
| 45 | #### <a id="alerts"></a> Email Alerts |
| 46 | |
| 47 | The Admin → Notification settings do not get copied on clone or sync, |
| 48 | and it is not possible to push such settings from one repository to |
| 49 | another. We did this on purpose because you may have a network of peer |
| 50 | repositories, and you only want one repository sending email alerts. If |
| 51 | Fossil were to automatically replicate the email alert settings to a |
| 52 | separate repository, subscribers would get multiple alerts for each |
| 53 | event, which would be *bad.* |
| 54 | |
| 55 | The only element of the email alert configuration that can be pulled |
| 56 | over the sync protocol on demand is the subscriber list, via |
| 57 | [`fossil config pull subscriber`][cfg]. |
| 58 | |
| 59 | |
| 60 | #### <a id="project"></a> Project Configuration |
| 61 | |
| 62 | This is normally generated once during `fossil init` and never changed, |
| 63 | so Fossil doesn’t pull this information without being forced, on |
| 64 | purpose. You could accidentally merge two separate Fossil repos by |
| 65 | pushing one repo’s project config up to another, for example. |
| 66 | |
| 67 | |
| 68 | #### <a id="other-cfg"></a> Others |
| 69 | |
| 70 | A repo’s URL aliases, [interwiki configuration](./interwiki.md), and |
| 71 | [ticket customizations](./custom_tcket.wiki) also do not normally sync. |
| 72 | |
| 73 | [cfg]: /help?cmd=configuration |
| 74 | |
| 75 | |
| 76 | |
| 77 | ## <a id="private"></a> Private Branches |
| 78 | |
| 79 | The very nature of Fossil’s [private branch feature][pbr] ensures that |
| @@ -92,11 +129,11 @@ | |
| 129 | source of truth, those users still syncing with `svr2` won’t have their |
| 130 | commits pushed up to `svr1` unless you’ve set up bidirectional sync, |
| 131 | rather than have the two backup servers do `pull` only. |
| 132 | |
| 133 | |
| 134 | # <a id="sync-solution"></a> Solution 1: Explicit Pulls |
| 135 | |
| 136 | The following script solves most of the above problems for the use case |
| 137 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 138 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 139 | the remote as a user with Setup capability, however. |
| @@ -119,11 +156,11 @@ | |
| 156 | that it will continue to have information that the remote says should |
| 157 | not exist any more. That would be not so much a “backup” as an |
| 158 | “archive,” which might not be what you want. |
| 159 | |
| 160 | |
| 161 | # <a id="sql-solution"></a> Solution 2: SQL-Level Backup |
| 162 | |
| 163 | The first method doesn’t get you a copy of the remote’s |
| 164 | [private branches][pbr], on purpose. It may also miss other info on the |
| 165 | remote, such as SQL-level customizations that the sync protocol can’t |
| 166 | see. (Some [ticket system customization][tkt] schemes rely on this ability, for example.) You can |
| 167 |