Fossil SCM
Clarity pass on the autosync section of the gitusers doc
Commit
80963ffeda3650dfe95f8c18adf3f5871cd9b20eaae26d9ed13481bdacb06304
Parent
bd7b10998d5cb67…
1 file changed
+17
-20
+17
-20
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -602,38 +602,35 @@ | ||
| 602 | 602 | focus on the fact that you’ve made it easier for [forks] to occur in the |
| 603 | 603 | development history by disabling autosync. If all three machines were |
| 604 | 604 | online and syncing at the time the sequence above began, Bob would |
| 605 | 605 | have been warned in step 2 that committing to the central repo would |
| 606 | 606 | create a fork and would be invited to fix it before committing. |
| 607 | -Likewise, Alice would be warned about the new tip-of-branch commit the | |
| 608 | -next time she triggered an implicit autosync at step 3. | |
| 607 | +Likewise, Alice will be warned about the new tip-of-branch commit the | |
| 608 | +next time she triggers an implicit autosync at step 3, bringing Bob’s | |
| 609 | +changes down in a non-conflicting manner, allowing work to proceed | |
| 610 | +without fuss. | |
| 611 | + | |
| 612 | +Another way the above scenario could go down is that by the next time | |
| 613 | +Alice does something to trigger an autosync, she’s done something in the | |
| 614 | +meantime to create *another* fork. Alice is then invited to fix the | |
| 615 | +second fork in the same manner as Bob was, getting both parties back | |
| 616 | +onto a single track as expeditiously as possible, requiring no direct | |
| 617 | +communication. This moves the synchronization point out of the | |
| 618 | +expensive human-time workflow and into the software system, where it’s | |
| 619 | +cheapest to resolve. | |
| 609 | 620 | |
| 610 | 621 | Solving this class of problem in as automated a manner as is possible is |
| 611 | -why autosync is enabled by default. It provides Fossil with most of the | |
| 612 | -advantages of a centralized version control system while retaining the | |
| 613 | -advantages of distributed version control. | |
| 614 | - | |
| 615 | -With autosync enabled, Fossil will warn Bob in step 2 above that his | |
| 616 | -commit to the shared working branch will create a fork; he could force | |
| 617 | -it, but he is instead invited to fix the fork before committing. When | |
| 618 | -Alice then does something to trigger an autosync, if she hasn’t done | |
| 619 | -anything in the meantime to create *another* fork, Bob’s changes come | |
| 620 | -down in a non-conflicting manner and work proceeds without fuss. | |
| 621 | -Otherwise, Alice is invited to fix the second fork in the same manner, | |
| 622 | -getting both parties back onto a single track as expeditiously as | |
| 623 | -possible, requiring no direct communication. This moves the | |
| 624 | -synchronization point out of the expensive human-time workflow and into | |
| 625 | -the software system, where it’s cheapest to resolve. | |
| 626 | - | |
| 627 | -The advantages of autosync are: | |
| 622 | +why Fossil enables autosync by default. It provides Fossil with most of | |
| 623 | +the advantages of a centralized version control system while retaining | |
| 624 | +the advantages of distributed version control. With autosync enabled: | |
| 628 | 625 | |
| 629 | 626 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 630 | 627 | machine can connect to the remote repository. At need, you can go |
| 631 | 628 | off-network and continue work atop the last version you synced with |
| 632 | 629 | the remote. |
| 633 | 630 | |
| 634 | -2. It provides immediate off-machine backup of your commits. Unlike | |
| 631 | +2. You get implicit off-machine backup of your commits. Unlike | |
| 635 | 632 | centralized version control, though, you can still work while |
| 636 | 633 | disconnected; your changes will sync up with the remote once you get |
| 637 | 634 | back online. |
| 638 | 635 | |
| 639 | 636 | 3. Because there is [little distinction][bu] between the clones in the Fossil |
| 640 | 637 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -602,38 +602,35 @@ | |
| 602 | focus on the fact that you’ve made it easier for [forks] to occur in the |
| 603 | development history by disabling autosync. If all three machines were |
| 604 | online and syncing at the time the sequence above began, Bob would |
| 605 | have been warned in step 2 that committing to the central repo would |
| 606 | create a fork and would be invited to fix it before committing. |
| 607 | Likewise, Alice would be warned about the new tip-of-branch commit the |
| 608 | next time she triggered an implicit autosync at step 3. |
| 609 | |
| 610 | Solving this class of problem in as automated a manner as is possible is |
| 611 | why autosync is enabled by default. It provides Fossil with most of the |
| 612 | advantages of a centralized version control system while retaining the |
| 613 | advantages of distributed version control. |
| 614 | |
| 615 | With autosync enabled, Fossil will warn Bob in step 2 above that his |
| 616 | commit to the shared working branch will create a fork; he could force |
| 617 | it, but he is instead invited to fix the fork before committing. When |
| 618 | Alice then does something to trigger an autosync, if she hasn’t done |
| 619 | anything in the meantime to create *another* fork, Bob’s changes come |
| 620 | down in a non-conflicting manner and work proceeds without fuss. |
| 621 | Otherwise, Alice is invited to fix the second fork in the same manner, |
| 622 | getting both parties back onto a single track as expeditiously as |
| 623 | possible, requiring no direct communication. This moves the |
| 624 | synchronization point out of the expensive human-time workflow and into |
| 625 | the software system, where it’s cheapest to resolve. |
| 626 | |
| 627 | The advantages of autosync are: |
| 628 | |
| 629 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 630 | machine can connect to the remote repository. At need, you can go |
| 631 | off-network and continue work atop the last version you synced with |
| 632 | the remote. |
| 633 | |
| 634 | 2. It provides immediate off-machine backup of your commits. Unlike |
| 635 | centralized version control, though, you can still work while |
| 636 | disconnected; your changes will sync up with the remote once you get |
| 637 | back online. |
| 638 | |
| 639 | 3. Because there is [little distinction][bu] between the clones in the Fossil |
| 640 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -602,38 +602,35 @@ | |
| 602 | focus on the fact that you’ve made it easier for [forks] to occur in the |
| 603 | development history by disabling autosync. If all three machines were |
| 604 | online and syncing at the time the sequence above began, Bob would |
| 605 | have been warned in step 2 that committing to the central repo would |
| 606 | create a fork and would be invited to fix it before committing. |
| 607 | Likewise, Alice will be warned about the new tip-of-branch commit the |
| 608 | next time she triggers an implicit autosync at step 3, bringing Bob’s |
| 609 | changes down in a non-conflicting manner, allowing work to proceed |
| 610 | without fuss. |
| 611 | |
| 612 | Another way the above scenario could go down is that by the next time |
| 613 | Alice does something to trigger an autosync, she’s done something in the |
| 614 | meantime to create *another* fork. Alice is then invited to fix the |
| 615 | second fork in the same manner as Bob was, getting both parties back |
| 616 | onto a single track as expeditiously as possible, requiring no direct |
| 617 | communication. This moves the synchronization point out of the |
| 618 | expensive human-time workflow and into the software system, where it’s |
| 619 | cheapest to resolve. |
| 620 | |
| 621 | Solving this class of problem in as automated a manner as is possible is |
| 622 | why Fossil enables autosync by default. It provides Fossil with most of |
| 623 | the advantages of a centralized version control system while retaining |
| 624 | the advantages of distributed version control. With autosync enabled: |
| 625 | |
| 626 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 627 | machine can connect to the remote repository. At need, you can go |
| 628 | off-network and continue work atop the last version you synced with |
| 629 | the remote. |
| 630 | |
| 631 | 2. You get implicit off-machine backup of your commits. Unlike |
| 632 | centralized version control, though, you can still work while |
| 633 | disconnected; your changes will sync up with the remote once you get |
| 634 | back online. |
| 635 | |
| 636 | 3. Because there is [little distinction][bu] between the clones in the Fossil |
| 637 |