Fossil SCM
Update the change log and the sync protocol documentation for the new check-in locking mechanism that tries to prevent race-condition forks.
Commit
2d7a8a832faa5ab0113c647f587f78cf0e866c0517d31478d04d7a73063a1bc1
Parent
2655a2d405ac3c5…
2 files changed
+3
+22
-1
+3
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -60,10 +60,13 @@ | ||
| 60 | 60 | punctuation. |
| 61 | 61 | * Automatically disapprove pending moderation requests for a user when |
| 62 | 62 | that user is deleted. This helps in dealing with spam-bots. |
| 63 | 63 | * Improvements to the "Capability Summary" section in the |
| 64 | 64 | [/help?cmd=/secaudit0|Security Audit] web-page. |
| 65 | + * Use new "ci-lock" and "ci-lock-failed" pragmas in the | |
| 66 | + [./sync.wiki|sync protocol] to try to prevent accident forks | |
| 67 | + caused by concurrent commits when operating in auto-sync mode. | |
| 65 | 68 | |
| 66 | 69 | <a name='v2_8'></a> |
| 67 | 70 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 68 | 71 | |
| 69 | 72 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 70 | 73 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -60,10 +60,13 @@ | |
| 60 | punctuation. |
| 61 | * Automatically disapprove pending moderation requests for a user when |
| 62 | that user is deleted. This helps in dealing with spam-bots. |
| 63 | * Improvements to the "Capability Summary" section in the |
| 64 | [/help?cmd=/secaudit0|Security Audit] web-page. |
| 65 | |
| 66 | <a name='v2_8'></a> |
| 67 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 68 | |
| 69 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 70 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -60,10 +60,13 @@ | |
| 60 | punctuation. |
| 61 | * Automatically disapprove pending moderation requests for a user when |
| 62 | that user is deleted. This helps in dealing with spam-bots. |
| 63 | * Improvements to the "Capability Summary" section in the |
| 64 | [/help?cmd=/secaudit0|Security Audit] web-page. |
| 65 | * Use new "ci-lock" and "ci-lock-failed" pragmas in the |
| 66 | [./sync.wiki|sync protocol] to try to prevent accident forks |
| 67 | caused by concurrent commits when operating in auto-sync mode. |
| 68 | |
| 69 | <a name='v2_8'></a> |
| 70 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 71 | |
| 72 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 73 |
+22
-1
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -625,11 +625,11 @@ | ||
| 625 | 625 | |
| 626 | 626 | <p>New pragma names may be added to the protocol from time to time |
| 627 | 627 | in order to enhance the capabilities of Fossil. |
| 628 | 628 | Unknown pragmas are silently ignored, for backwards compatibility. |
| 629 | 629 | |
| 630 | -<p>The following are the known pragma names as of 2016-08-03: | |
| 630 | +<p>The following are the known pragma names as of 2019-06-30: | |
| 631 | 631 | |
| 632 | 632 | <ol> |
| 633 | 633 | <li><p><b>send-private</b> |
| 634 | 634 | <p>The send-private pragma instructs the server to send all of its |
| 635 | 635 | private artifacts to the client. The server will only obey this |
| @@ -677,10 +677,31 @@ | ||
| 677 | 677 | pragma indicates that there are differences in unversioned content |
| 678 | 678 | between the client and server and that content can only be transfered |
| 679 | 679 | in either direction. The server is willing to accept content from |
| 680 | 680 | the client because the client login has the "write-unversioned" |
| 681 | 681 | permission.</p> |
| 682 | + | |
| 683 | +<li><p><b>ci-lock</b> <i>CHECKIN-HASH CLIENT-ID</i></p> | |
| 684 | +<p>A client sends the "ci-lock" pragma to the server to indicate | |
| 685 | +that it is about to add a new check-in as a child of the | |
| 686 | +CHECKIN-HASH check-in and on the same branch as CHECKIN-HASH. | |
| 687 | +If some other client has already indicated that it was also | |
| 688 | +trying to commit against CHECKIN-HASH, that indicates that a | |
| 689 | +fork is about to occur, and the server will reply with | |
| 690 | +a "ci-lock-fail" pragma (see below). Check-in locks | |
| 691 | +automatically expire when the check-in actually occurs, or | |
| 692 | +after a timeout (currently 24-hours but subject to change). | |
| 693 | + | |
| 694 | +<li><p><b>ci-lock-fail</b> <i>LOGIN MTIME</i></p> | |
| 695 | +<p>When a server receives two or more "ci-lock" pragma messages | |
| 696 | +for the same check-in but from different clients, the second a | |
| 697 | +subsequent ci-lock will provoke a ci-lock-fail pragma in the | |
| 698 | +reply to let the client know that it if continues with the | |
| 699 | +check-in it will likely generate a fork. The LOGIN and MTIME | |
| 700 | +arguments are intended to provide information to the client to | |
| 701 | +help it generate a more useful error message. | |
| 702 | +</p> | |
| 682 | 703 | |
| 683 | 704 | </ol> |
| 684 | 705 | |
| 685 | 706 | <h3>3.12 Comment Cards</h3> |
| 686 | 707 | |
| 687 | 708 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -625,11 +625,11 @@ | |
| 625 | |
| 626 | <p>New pragma names may be added to the protocol from time to time |
| 627 | in order to enhance the capabilities of Fossil. |
| 628 | Unknown pragmas are silently ignored, for backwards compatibility. |
| 629 | |
| 630 | <p>The following are the known pragma names as of 2016-08-03: |
| 631 | |
| 632 | <ol> |
| 633 | <li><p><b>send-private</b> |
| 634 | <p>The send-private pragma instructs the server to send all of its |
| 635 | private artifacts to the client. The server will only obey this |
| @@ -677,10 +677,31 @@ | |
| 677 | pragma indicates that there are differences in unversioned content |
| 678 | between the client and server and that content can only be transfered |
| 679 | in either direction. The server is willing to accept content from |
| 680 | the client because the client login has the "write-unversioned" |
| 681 | permission.</p> |
| 682 | |
| 683 | </ol> |
| 684 | |
| 685 | <h3>3.12 Comment Cards</h3> |
| 686 | |
| 687 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -625,11 +625,11 @@ | |
| 625 | |
| 626 | <p>New pragma names may be added to the protocol from time to time |
| 627 | in order to enhance the capabilities of Fossil. |
| 628 | Unknown pragmas are silently ignored, for backwards compatibility. |
| 629 | |
| 630 | <p>The following are the known pragma names as of 2019-06-30: |
| 631 | |
| 632 | <ol> |
| 633 | <li><p><b>send-private</b> |
| 634 | <p>The send-private pragma instructs the server to send all of its |
| 635 | private artifacts to the client. The server will only obey this |
| @@ -677,10 +677,31 @@ | |
| 677 | pragma indicates that there are differences in unversioned content |
| 678 | between the client and server and that content can only be transfered |
| 679 | in either direction. The server is willing to accept content from |
| 680 | the client because the client login has the "write-unversioned" |
| 681 | permission.</p> |
| 682 | |
| 683 | <li><p><b>ci-lock</b> <i>CHECKIN-HASH CLIENT-ID</i></p> |
| 684 | <p>A client sends the "ci-lock" pragma to the server to indicate |
| 685 | that it is about to add a new check-in as a child of the |
| 686 | CHECKIN-HASH check-in and on the same branch as CHECKIN-HASH. |
| 687 | If some other client has already indicated that it was also |
| 688 | trying to commit against CHECKIN-HASH, that indicates that a |
| 689 | fork is about to occur, and the server will reply with |
| 690 | a "ci-lock-fail" pragma (see below). Check-in locks |
| 691 | automatically expire when the check-in actually occurs, or |
| 692 | after a timeout (currently 24-hours but subject to change). |
| 693 | |
| 694 | <li><p><b>ci-lock-fail</b> <i>LOGIN MTIME</i></p> |
| 695 | <p>When a server receives two or more "ci-lock" pragma messages |
| 696 | for the same check-in but from different clients, the second a |
| 697 | subsequent ci-lock will provoke a ci-lock-fail pragma in the |
| 698 | reply to let the client know that it if continues with the |
| 699 | check-in it will likely generate a fork. The LOGIN and MTIME |
| 700 | arguments are intended to provide information to the client to |
| 701 | help it generate a more useful error message. |
| 702 | </p> |
| 703 | |
| 704 | </ol> |
| 705 | |
| 706 | <h3>3.12 Comment Cards</h3> |
| 707 | |
| 708 |