Fossil SCM
Clarity pass on the new material in the Autosync section of the gitusers doc.
Commit
cc55044b3902aba809dbceea3eb1b9c2e19ef6302aadf356c2e15078acb42469
Parent
7e77e29d1646563…
1 file changed
+25
-25
+25
-25
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -590,40 +590,40 @@ | ||
| 590 | 590 | Let’s say that you have a typical server-and-workstations model with two |
| 591 | 591 | working clones on different machines, that you have disabled autosync, |
| 592 | 592 | and that this common sequence then occurs: |
| 593 | 593 | |
| 594 | 594 | 1. Alice commits to her local clone and *separately* pushes the change |
| 595 | - up to the central machine C in typical Git fashion. | |
| 595 | + up to Condor — their central server — in typical Git fashion. | |
| 596 | 596 | 2. Bob does the same. |
| 597 | -3. Alice says “`fossil pull`” to bring changes from C down, sees what | |
| 598 | - Bob did to their shared working branch, and becomes most wrathful. | |
| 597 | +3. Alice brings Bob’s changes down from Condor with “`fossil pull`,” sees | |
| 598 | + what he did to their shared working branch, and becomes most wrathful. | |
| 599 | 599 | (Tsk, tsk.) |
| 600 | 600 | |
| 601 | -We’ll get to what you do about this situation below, but for now let us | |
| 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 | |
| 601 | +We’ll get to what you do about this situation [below](#reset), but for | |
| 602 | +now let us focus on the fact that disabling autosync makes it easier for | |
| 603 | +[forks] to occur in the development history. If all three machines had | |
| 604 | +been 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 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: | |
| 607 | +Likewise, it would allow Fossil to warn Alice about the new | |
| 608 | +tip-of-branch commit the next time she triggers an implicit autosync at | |
| 609 | +step 3, giving her a chance to bring Bob’s changes down in a | |
| 610 | +non-conflicting manner, allowing work to proceed with minimal fuss. | |
| 611 | + | |
| 612 | +Fossil, being a distributed version control system, cannot guarantee | |
| 613 | +that sequence of events. Because it allows Alice’s work to proceed | |
| 614 | +asynchronously, it gives her the chance to create *another* inadvertent | |
| 615 | +fork before she can trigger an autosync. This is not a serious problem; | |
| 616 | +Fossil resolves it the same way as with Bob, by inviting her to fix this | |
| 617 | +second fork in the same manner as it did with Bob. It gets both parties | |
| 618 | +back onto a single track as expeditiously as possible by moving 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 | +Autosync provides Fossil with most of the advantages of a centralized | |
| 623 | +version control system while retaining the advantages of distributed | |
| 624 | +version control: | |
| 625 | 625 | |
| 626 | 626 | 1. Your work stays synced up with your coworkers’ efforts as long as your |
| 627 | 627 | machine can connect to the remote repository. At need, you can go |
| 628 | 628 | off-network and continue work atop the last version you synced with |
| 629 | 629 | the remote. |
| 630 | 630 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -590,40 +590,40 @@ | |
| 590 | Let’s say that you have a typical server-and-workstations model with two |
| 591 | working clones on different machines, that you have disabled autosync, |
| 592 | and that this common sequence then occurs: |
| 593 | |
| 594 | 1. Alice commits to her local clone and *separately* pushes the change |
| 595 | up to the central machine C in typical Git fashion. |
| 596 | 2. Bob does the same. |
| 597 | 3. Alice says “`fossil pull`” to bring changes from C down, sees what |
| 598 | Bob did to their shared working branch, and becomes most wrathful. |
| 599 | (Tsk, tsk.) |
| 600 | |
| 601 | We’ll get to what you do about this situation below, but for now let us |
| 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 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -590,40 +590,40 @@ | |
| 590 | Let’s say that you have a typical server-and-workstations model with two |
| 591 | working clones on different machines, that you have disabled autosync, |
| 592 | and that this common sequence then occurs: |
| 593 | |
| 594 | 1. Alice commits to her local clone and *separately* pushes the change |
| 595 | up to Condor — their central server — in typical Git fashion. |
| 596 | 2. Bob does the same. |
| 597 | 3. Alice brings Bob’s changes down from Condor with “`fossil pull`,” sees |
| 598 | what he did to their shared working branch, and becomes most wrathful. |
| 599 | (Tsk, tsk.) |
| 600 | |
| 601 | We’ll get to what you do about this situation [below](#reset), but for |
| 602 | now let us focus on the fact that disabling autosync makes it easier for |
| 603 | [forks] to occur in the development history. If all three machines had |
| 604 | been 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, it would allow Fossil to warn Alice about the new |
| 608 | tip-of-branch commit the next time she triggers an implicit autosync at |
| 609 | step 3, giving her a chance to bring Bob’s changes down in a |
| 610 | non-conflicting manner, allowing work to proceed with minimal fuss. |
| 611 | |
| 612 | Fossil, being a distributed version control system, cannot guarantee |
| 613 | that sequence of events. Because it allows Alice’s work to proceed |
| 614 | asynchronously, it gives her the chance to create *another* inadvertent |
| 615 | fork before she can trigger an autosync. This is not a serious problem; |
| 616 | Fossil resolves it the same way as with Bob, by inviting her to fix this |
| 617 | second fork in the same manner as it did with Bob. It gets both parties |
| 618 | back onto a single track as expeditiously as possible by moving 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 | Autosync provides Fossil with most of the advantages of a centralized |
| 623 | version control system while retaining the advantages of distributed |
| 624 | version control: |
| 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 |