Fossil SCM
Added a motivating example to the "Autosync" section of the gitusers doc, showing why it's better to let the software system resolve conflicts asynchronously than to force Alice and Bob to fight it out, moving the synchronization point out into the human-time workflow.
Commit
8975e8daf19df0c5d2cdb914458a3a4af4e4878592e115e2fe00fbf22b0d5237
Parent
35b2307f9c27940…
1 file changed
+38
-9
+38
-9
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -581,19 +581,47 @@ | ||
| 581 | 581 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 582 | 582 | it off: |
| 583 | 583 | |
| 584 | 584 | fossil set autosync 0 |
| 585 | 585 | |
| 586 | -However, it’s better to understand what the feature does and why it is enabled by | |
| 587 | -default. | |
| 588 | - | |
| 589 | -When autosync is enabled, Fossil automatically pushes your changes | |
| 590 | -to the remote server whenever you "`fossil commit`", and it | |
| 591 | -pulls all remote changes down to your local clone of the repository as | |
| 592 | -part of a "`fossil update`". | |
| 593 | -This provides most of the advantages of a centralized version control | |
| 594 | -system while retaining the advantages of distributed version control: | |
| 586 | +Let’s say that you have a typical server-and-workstations model with two | |
| 587 | +working clones on different machines, that you have disabled autosync, | |
| 588 | +and that this common sequence then occurs: | |
| 589 | + | |
| 590 | +1. Alice commits to her local clone and *separately* pushes the change | |
| 591 | + up to the central machine C in typical Git fashion. | |
| 592 | +2. Bob does the same. | |
| 593 | +3. Alice says “`fossil pull`” to bring changes from C down, sees what | |
| 594 | + Bob did to their shared working branch, and becomes wrothful. | |
| 595 | + | |
| 596 | +We’ll get to what you do about this situation below, but for now let us | |
| 597 | +focus on the fact that you’ve made it easier for [forks] to occur in the | |
| 598 | +development history by disabling autosync. If all three machines were | |
| 599 | +online and syncing at the time the sequence above began, Bob would | |
| 600 | +have been warned in step 2 that committing to the central repo would | |
| 601 | +create a fork and would be invited to fix it before committing. | |
| 602 | +Likewise, Alice would be warned about the new tip-of-branch commit the | |
| 603 | +next time she triggered an implicit autosync at step 3. | |
| 604 | + | |
| 605 | +Solving this class of problem in as automated a manner as is possible is | |
| 606 | +why autosync is enabled by default. It provides Fossil with most of the | |
| 607 | +advantages of a centralized version control system while retaining the | |
| 608 | +advantages of distributed version control. | |
| 609 | + | |
| 610 | +With autosync enabled, Fossil will warn Bob in step 2 above that his | |
| 611 | +commit to the shared working branch will create a fork; he could force | |
| 612 | +it, but he is instead invited to fix the fork before committing. When | |
| 613 | +Alice then does something to trigger an autosync, if she hasn’t done | |
| 614 | +anything in the meantime to create *another* fork, Bob’s changes come | |
| 615 | +down in a non-conflicting manner and work proceeds without fuss. | |
| 616 | +Otherwise, Alice is invited to fix the second fork in the same manner, | |
| 617 | +getting both parties back onto a single track as expeditiously as | |
| 618 | +possible, requiring no direct communication. This moves the | |
| 619 | +synchronization point out of the expensive human-time workflow and into | |
| 620 | +the software system, where it’s cheapest to resolve. | |
| 621 | + | |
| 622 | +The advantages of autosync are: | |
| 595 | 623 | |
| 596 | 624 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 597 | 625 | machine can connect to the remote repository. At need, you can go |
| 598 | 626 | off-network and continue work atop the last version you synced with |
| 599 | 627 | the remote. |
| @@ -612,10 +640,11 @@ | ||
| 612 | 640 | remote. If the failed remote comes back later, it can sync with the |
| 613 | 641 | new central version, then perhaps take over as the primary source of |
| 614 | 642 | truth once again. |
| 615 | 643 | |
| 616 | 644 | [bu]: ./backup.md |
| 645 | +[forks]: ./branching.wiki | |
| 617 | 646 | [setup]: ./caps/admin-v-setup.md#apsu |
| 618 | 647 | [wflow]: ./concepts.wiki#workflow |
| 619 | 648 | |
| 620 | 649 | |
| 621 | 650 | <a id="syncall"></a> |
| 622 | 651 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -581,19 +581,47 @@ | |
| 581 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 582 | it off: |
| 583 | |
| 584 | fossil set autosync 0 |
| 585 | |
| 586 | However, it’s better to understand what the feature does and why it is enabled by |
| 587 | default. |
| 588 | |
| 589 | When autosync is enabled, Fossil automatically pushes your changes |
| 590 | to the remote server whenever you "`fossil commit`", and it |
| 591 | pulls all remote changes down to your local clone of the repository as |
| 592 | part of a "`fossil update`". |
| 593 | This provides most of the advantages of a centralized version control |
| 594 | system while retaining the advantages of distributed version control: |
| 595 | |
| 596 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 597 | machine can connect to the remote repository. At need, you can go |
| 598 | off-network and continue work atop the last version you synced with |
| 599 | the remote. |
| @@ -612,10 +640,11 @@ | |
| 612 | remote. If the failed remote comes back later, it can sync with the |
| 613 | new central version, then perhaps take over as the primary source of |
| 614 | truth once again. |
| 615 | |
| 616 | [bu]: ./backup.md |
| 617 | [setup]: ./caps/admin-v-setup.md#apsu |
| 618 | [wflow]: ./concepts.wiki#workflow |
| 619 | |
| 620 | |
| 621 | <a id="syncall"></a> |
| 622 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -581,19 +581,47 @@ | |
| 581 | equivalent in Git. If you want Fossil to behave like Git, you can turn |
| 582 | it off: |
| 583 | |
| 584 | fossil set autosync 0 |
| 585 | |
| 586 | Let’s say that you have a typical server-and-workstations model with two |
| 587 | working clones on different machines, that you have disabled autosync, |
| 588 | and that this common sequence then occurs: |
| 589 | |
| 590 | 1. Alice commits to her local clone and *separately* pushes the change |
| 591 | up to the central machine C in typical Git fashion. |
| 592 | 2. Bob does the same. |
| 593 | 3. Alice says “`fossil pull`” to bring changes from C down, sees what |
| 594 | Bob did to their shared working branch, and becomes wrothful. |
| 595 | |
| 596 | We’ll get to what you do about this situation below, but for now let us |
| 597 | focus on the fact that you’ve made it easier for [forks] to occur in the |
| 598 | development history by disabling autosync. If all three machines were |
| 599 | online and syncing at the time the sequence above began, Bob would |
| 600 | have been warned in step 2 that committing to the central repo would |
| 601 | create a fork and would be invited to fix it before committing. |
| 602 | Likewise, Alice would be warned about the new tip-of-branch commit the |
| 603 | next time she triggered an implicit autosync at step 3. |
| 604 | |
| 605 | Solving this class of problem in as automated a manner as is possible is |
| 606 | why autosync is enabled by default. It provides Fossil with most of the |
| 607 | advantages of a centralized version control system while retaining the |
| 608 | advantages of distributed version control. |
| 609 | |
| 610 | With autosync enabled, Fossil will warn Bob in step 2 above that his |
| 611 | commit to the shared working branch will create a fork; he could force |
| 612 | it, but he is instead invited to fix the fork before committing. When |
| 613 | Alice then does something to trigger an autosync, if she hasn’t done |
| 614 | anything in the meantime to create *another* fork, Bob’s changes come |
| 615 | down in a non-conflicting manner and work proceeds without fuss. |
| 616 | Otherwise, Alice is invited to fix the second fork in the same manner, |
| 617 | getting both parties back onto a single track as expeditiously as |
| 618 | possible, requiring no direct communication. This moves the |
| 619 | synchronization point out of the expensive human-time workflow and into |
| 620 | the software system, where it’s cheapest to resolve. |
| 621 | |
| 622 | The advantages of autosync are: |
| 623 | |
| 624 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 625 | machine can connect to the remote repository. At need, you can go |
| 626 | off-network and continue work atop the last version you synced with |
| 627 | the remote. |
| @@ -612,10 +640,11 @@ | |
| 640 | remote. If the failed remote comes back later, it can sync with the |
| 641 | new central version, then perhaps take over as the primary source of |
| 642 | truth once again. |
| 643 | |
| 644 | [bu]: ./backup.md |
| 645 | [forks]: ./branching.wiki |
| 646 | [setup]: ./caps/admin-v-setup.md#apsu |
| 647 | [wflow]: ./concepts.wiki#workflow |
| 648 | |
| 649 | |
| 650 | <a id="syncall"></a> |
| 651 |