Fossil SCM
Greatly expanded the "Autosync" section of the gitusers doc. Among other things, it now references the new backup.md doc.
Commit
3ddc1d9458b10548ea284d335b2dc802af2f397b9c5a9f889288d01777cc15d2
Parent
78c0c55a41a161d…
1 file changed
+39
-13
+39
-13
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -191,24 +191,50 @@ | ||
| 191 | 191 | |
| 192 | 192 | |
| 193 | 193 | <a id="autosync"></a> |
| 194 | 194 | ## Autosync |
| 195 | 195 | |
| 196 | -Fossil has a feature called "[autosync][5]". Autosync defaults on. | |
| 196 | +Fossil’s [autosync][wflow] feature, normally enabled, has no | |
| 197 | +equivalent in Git. If you want Fossil to behave like Git, you will turn | |
| 198 | +it off: | |
| 199 | + | |
| 200 | + fossil set autosync 0 | |
| 201 | + | |
| 202 | +It’s better to understand what the feature does and why it is enabled by | |
| 203 | +default. | |
| 204 | + | |
| 197 | 205 | When autosync is enabled, Fossil automatically pushes your changes |
| 198 | -to the remote server whenever you "`fossil commit`". It also automatically | |
| 199 | -pulls all remote changes down to your local repository before you | |
| 200 | -"`fossil update`". | |
| 201 | - | |
| 202 | -[5]: ./concepts.wiki#workflow | |
| 203 | - | |
| 204 | -Autosync provides most of the advantages of a centralized version | |
| 205 | -control system while retaining the advantages of distributed version | |
| 206 | -control. Your work stays synced up with your coworkers at all times. | |
| 207 | -If your local machine dies catastrophically, you haven't lost any | |
| 208 | -(committed) work. But you can still work and commit while off network, | |
| 209 | -with changes resyncing automatically when you get back on-line. | |
| 206 | +to the remote server whenever you "`fossil commit`", and it | |
| 207 | +pulls all remote changes down to your local clone of the repository as | |
| 208 | +part of a "`fossil update`". | |
| 209 | +This provides most of the advantages of a centralized version control | |
| 210 | +system while retaining the advantages of distributed version control: | |
| 211 | + | |
| 212 | +1. Your work stays synced up with your coworkers as long as your | |
| 213 | + machine can connect to the remote repository, but at need, you can go | |
| 214 | + off-network and continue work atop the last version you sync’d with | |
| 215 | + the remote. | |
| 216 | + | |
| 217 | +2. It provides immediate off-machine backup of your commits. Unlike | |
| 218 | + centralized version control, though, you can still work while | |
| 219 | + disconnected; your changes will sync up with the remote once you get | |
| 220 | + back online. | |
| 221 | + | |
| 222 | +3. Because there is little distinction betwen the clones in the Fossil | |
| 223 | + model — unlike in Git, where clones often quickly diverge from each | |
| 224 | + other, usually on purpose — the backup advantage applies in inverse | |
| 225 | + as well: if the remote server falls over dead, one of those with a | |
| 226 | + clone of that repository can stand it back up, and everyone can get | |
| 227 | + back to work. If the remote comes back later, it can sync with the | |
| 228 | + new central version, then perhaps take over as the primary source of | |
| 229 | + truth once again. | |
| 230 | + | |
| 231 | + (There are caveats to this, [covered elsewhere][bu].) | |
| 232 | + | |
| 233 | +[bu]: ./backup.md | |
| 234 | +[setup]: ./caps/admin-v-setup.md#apsu | |
| 235 | +[wflow]: ./concepts.wiki#workflow | |
| 210 | 236 | |
| 211 | 237 | |
| 212 | 238 | <a id="syncall"></a> |
| 213 | 239 | ## Syncing Is All-Or-Nothing |
| 214 | 240 | |
| 215 | 241 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -191,24 +191,50 @@ | |
| 191 | |
| 192 | |
| 193 | <a id="autosync"></a> |
| 194 | ## Autosync |
| 195 | |
| 196 | Fossil has a feature called "[autosync][5]". Autosync defaults on. |
| 197 | When autosync is enabled, Fossil automatically pushes your changes |
| 198 | to the remote server whenever you "`fossil commit`". It also automatically |
| 199 | pulls all remote changes down to your local repository before you |
| 200 | "`fossil update`". |
| 201 | |
| 202 | [5]: ./concepts.wiki#workflow |
| 203 | |
| 204 | Autosync provides most of the advantages of a centralized version |
| 205 | control system while retaining the advantages of distributed version |
| 206 | control. Your work stays synced up with your coworkers at all times. |
| 207 | If your local machine dies catastrophically, you haven't lost any |
| 208 | (committed) work. But you can still work and commit while off network, |
| 209 | with changes resyncing automatically when you get back on-line. |
| 210 | |
| 211 | |
| 212 | <a id="syncall"></a> |
| 213 | ## Syncing Is All-Or-Nothing |
| 214 | |
| 215 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -191,24 +191,50 @@ | |
| 191 | |
| 192 | |
| 193 | <a id="autosync"></a> |
| 194 | ## Autosync |
| 195 | |
| 196 | Fossil’s [autosync][wflow] feature, normally enabled, has no |
| 197 | equivalent in Git. If you want Fossil to behave like Git, you will turn |
| 198 | it off: |
| 199 | |
| 200 | fossil set autosync 0 |
| 201 | |
| 202 | It’s better to understand what the feature does and why it is enabled by |
| 203 | default. |
| 204 | |
| 205 | When autosync is enabled, Fossil automatically pushes your changes |
| 206 | to the remote server whenever you "`fossil commit`", and it |
| 207 | pulls all remote changes down to your local clone of the repository as |
| 208 | part of a "`fossil update`". |
| 209 | This provides most of the advantages of a centralized version control |
| 210 | system while retaining the advantages of distributed version control: |
| 211 | |
| 212 | 1. Your work stays synced up with your coworkers as long as your |
| 213 | machine can connect to the remote repository, but at need, you can go |
| 214 | off-network and continue work atop the last version you sync’d with |
| 215 | the remote. |
| 216 | |
| 217 | 2. It provides immediate off-machine backup of your commits. Unlike |
| 218 | centralized version control, though, you can still work while |
| 219 | disconnected; your changes will sync up with the remote once you get |
| 220 | back online. |
| 221 | |
| 222 | 3. Because there is little distinction betwen the clones in the Fossil |
| 223 | model — unlike in Git, where clones often quickly diverge from each |
| 224 | other, usually on purpose — the backup advantage applies in inverse |
| 225 | as well: if the remote server falls over dead, one of those with a |
| 226 | clone of that repository can stand it back up, and everyone can get |
| 227 | back to work. If the remote comes back later, it can sync with the |
| 228 | new central version, then perhaps take over as the primary source of |
| 229 | truth once again. |
| 230 | |
| 231 | (There are caveats to this, [covered elsewhere][bu].) |
| 232 | |
| 233 | [bu]: ./backup.md |
| 234 | [setup]: ./caps/admin-v-setup.md#apsu |
| 235 | [wflow]: ./concepts.wiki#workflow |
| 236 | |
| 237 | |
| 238 | <a id="syncall"></a> |
| 239 | ## Syncing Is All-Or-Nothing |
| 240 | |
| 241 |