Fossil SCM
Added the "Autosync is Intransitive" section to the new backup doc.
Commit
1299d67786a63a58ae91c98a9c1b904af83df0059433d1a77cb1a72147c04287
Parent
ea57a2f72300e19…
1 file changed
+33
-1
+33
-1
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -45,10 +45,11 @@ | ||
| 45 | 45 | |
| 46 | 46 | Fossil purposefully doesn’t sync [shunned artifacts][shun]. If you want |
| 47 | 47 | your local clone to be a precise match to the remote, it needs to track |
| 48 | 48 | changes to the shun table as well. |
| 49 | 49 | |
| 50 | + | |
| 50 | 51 | |
| 51 | 52 | ## Universioned Artifacts |
| 52 | 53 | |
| 53 | 54 | Data in Fossil’s [unversioned artifacts table][uv] doesn’t sync down by |
| 54 | 55 | default unless you specifically ask for it. Like local configuration |
| @@ -55,14 +56,45 @@ | ||
| 55 | 56 | data, it doesn’t get pulled as part of a normal `fossil sync`, but |
| 56 | 57 | *unlike* the config data, you don’t get unversioned files as part of the |
| 57 | 58 | initial clone unless you ask for it by passing the `--unversioned/-u` |
| 58 | 59 | flag. |
| 59 | 60 | |
| 61 | + | |
| 62 | +## Autosync Is Intransitive | |
| 63 | + | |
| 64 | +If you’re using Fossil in a truly distributed mode, rather than the | |
| 65 | +simple central-and-clones model that is more common, there may be no | |
| 66 | +single source of truth in the network because Fossil’s autosync feature | |
| 67 | +isn’t transitive. | |
| 68 | + | |
| 69 | +That is, if you cloned from server A, and then you stand that up on a | |
| 70 | +server B, then if I clone from you as repository C, changes to B | |
| 71 | +autosync up to A, but not down to me on C until I do something locally | |
| 72 | +that triggers autosync. The inverse is also true: if I commit something | |
| 73 | +on C, it will autosync up to B, but A won’t get a copy until someone on | |
| 74 | +B does something to trigger autosync there. | |
| 75 | + | |
| 76 | +An easy way to run into this problem is to set up failover servers | |
| 77 | +`svr1` thru `svr3.example.com`, then set `svr2` and `svr3` up to sync | |
| 78 | +with the first. If all of the users normally clone from `svr1`, their | |
| 79 | +commits don’t get to `svr2` and `svr3` until something on one of the | |
| 80 | +servers pushes or pulls the changes down to the next server in the sync | |
| 81 | +chain. | |
| 82 | + | |
| 83 | +Likewise, if `svr1` falls over and all of the users re-point their local | |
| 84 | +clones at `svr2`, then `svr1` later reappears, `svr1` is likely to | |
| 85 | +remain a stale copy of the old version of the repository until someone | |
| 86 | +causes it to sync with `svr2` or `svr3` to catch up again. And then if | |
| 87 | +you originally designed the sync scheme to treat `svr1` as the primary | |
| 88 | +source of truth, those users still syncing with `svr2` won’t have their | |
| 89 | +commits pushed up to `svr1` unless you’ve set up bidirectional sync, | |
| 90 | +rather than have the two backup servers do `pull` only. | |
| 91 | + | |
| 60 | 92 | |
| 61 | 93 | # Solutions |
| 62 | 94 | |
| 63 | -The following script solves all of the above problems for the use case | |
| 95 | +The following script solves most of the above problems for the use case | |
| 64 | 96 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 65 | 97 | but the normal Fossil sync protocol. It requires that you be logged into |
| 66 | 98 | the remote as a user with Setup capability. |
| 67 | 99 | |
| 68 | 100 | ---- |
| 69 | 101 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -45,10 +45,11 @@ | |
| 45 | |
| 46 | Fossil purposefully doesn’t sync [shunned artifacts][shun]. If you want |
| 47 | your local clone to be a precise match to the remote, it needs to track |
| 48 | changes to the shun table as well. |
| 49 | |
| 50 | |
| 51 | ## Universioned Artifacts |
| 52 | |
| 53 | Data in Fossil’s [unversioned artifacts table][uv] doesn’t sync down by |
| 54 | default unless you specifically ask for it. Like local configuration |
| @@ -55,14 +56,45 @@ | |
| 55 | data, it doesn’t get pulled as part of a normal `fossil sync`, but |
| 56 | *unlike* the config data, you don’t get unversioned files as part of the |
| 57 | initial clone unless you ask for it by passing the `--unversioned/-u` |
| 58 | flag. |
| 59 | |
| 60 | |
| 61 | # Solutions |
| 62 | |
| 63 | The following script solves all of the above problems for the use case |
| 64 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 65 | but the normal Fossil sync protocol. It requires that you be logged into |
| 66 | the remote as a user with Setup capability. |
| 67 | |
| 68 | ---- |
| 69 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -45,10 +45,11 @@ | |
| 45 | |
| 46 | Fossil purposefully doesn’t sync [shunned artifacts][shun]. If you want |
| 47 | your local clone to be a precise match to the remote, it needs to track |
| 48 | changes to the shun table as well. |
| 49 | |
| 50 | |
| 51 | |
| 52 | ## Universioned Artifacts |
| 53 | |
| 54 | Data in Fossil’s [unversioned artifacts table][uv] doesn’t sync down by |
| 55 | default unless you specifically ask for it. Like local configuration |
| @@ -55,14 +56,45 @@ | |
| 56 | data, it doesn’t get pulled as part of a normal `fossil sync`, but |
| 57 | *unlike* the config data, you don’t get unversioned files as part of the |
| 58 | initial clone unless you ask for it by passing the `--unversioned/-u` |
| 59 | flag. |
| 60 | |
| 61 | |
| 62 | ## Autosync Is Intransitive |
| 63 | |
| 64 | If you’re using Fossil in a truly distributed mode, rather than the |
| 65 | simple central-and-clones model that is more common, there may be no |
| 66 | single source of truth in the network because Fossil’s autosync feature |
| 67 | isn’t transitive. |
| 68 | |
| 69 | That is, if you cloned from server A, and then you stand that up on a |
| 70 | server B, then if I clone from you as repository C, changes to B |
| 71 | autosync up to A, but not down to me on C until I do something locally |
| 72 | that triggers autosync. The inverse is also true: if I commit something |
| 73 | on C, it will autosync up to B, but A won’t get a copy until someone on |
| 74 | B does something to trigger autosync there. |
| 75 | |
| 76 | An easy way to run into this problem is to set up failover servers |
| 77 | `svr1` thru `svr3.example.com`, then set `svr2` and `svr3` up to sync |
| 78 | with the first. If all of the users normally clone from `svr1`, their |
| 79 | commits don’t get to `svr2` and `svr3` until something on one of the |
| 80 | servers pushes or pulls the changes down to the next server in the sync |
| 81 | chain. |
| 82 | |
| 83 | Likewise, if `svr1` falls over and all of the users re-point their local |
| 84 | clones at `svr2`, then `svr1` later reappears, `svr1` is likely to |
| 85 | remain a stale copy of the old version of the repository until someone |
| 86 | causes it to sync with `svr2` or `svr3` to catch up again. And then if |
| 87 | you originally designed the sync scheme to treat `svr1` as the primary |
| 88 | source of truth, those users still syncing with `svr2` won’t have their |
| 89 | commits pushed up to `svr1` unless you’ve set up bidirectional sync, |
| 90 | rather than have the two backup servers do `pull` only. |
| 91 | |
| 92 | |
| 93 | # Solutions |
| 94 | |
| 95 | The following script solves most of the above problems for the use case |
| 96 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 97 | but the normal Fossil sync protocol. It requires that you be logged into |
| 98 | the remote as a user with Setup capability. |
| 99 | |
| 100 | ---- |
| 101 |