Fossil SCM
Typo and clarity fixes to the new fpp doc.
Commit
2194b4d13b7ec3333fb1dddaaa5fe2f349b31fbb6d72c11262c74d6cc23bfbfa
Parent
ce73819d0e08867…
1 file changed
+20
-20
+20
-20
| --- www/fpp.md | ||
| +++ www/fpp.md | ||
| @@ -7,30 +7,30 @@ | ||
| 7 | 7 | ## Background |
| 8 | 8 | |
| 9 | 9 | The default behavior of Fossil is that any developer who has push |
| 10 | 10 | privileges on a repository can push any content. Project-specific |
| 11 | 11 | policy choices, such as "don't land unapproved changes on trunk" |
| 12 | -or "don't reopen a closed ticket" are enforced adminstratively, not | |
| 13 | -by Fossil itself. Fossil maintains a detailed audit trail, so that policy | |
| 12 | +or "don't reopen a closed ticket" are enforced administratively, not | |
| 13 | +by Fossil itself. Fossil maintains a detailed audit trail so that policy | |
| 14 | 14 | violations can be traced back to their source, and so that |
| 15 | -violators can be duely reprimanded. Fossil also provides mechanisms | |
| 15 | +violators can be duly reprimanded. Fossil also provides mechanisms | |
| 16 | 16 | so that unapproved changes can be excised from critical branches without |
| 17 | 17 | deleting history. But by default, Fossil |
| 18 | 18 | does not attempt to disallow unauthorized changes from occurring in the |
| 19 | 19 | first place. |
| 20 | 20 | |
| 21 | 21 | Nothing can prevent a developer from making non-conforming and/or |
| 22 | -unauthorized change in a private client-side clone of a Fossil repository, | |
| 23 | -as the client-side repository is under the complete control of the | |
| 22 | +unauthorized change in a private client-side clone of a Fossil repository | |
| 23 | +since the client-side repository is under the complete control of the | |
| 24 | 24 | developer who owns it. |
| 25 | 25 | Any automatic policy enforcement must happen on the common repository |
| 26 | 26 | when the developer attempts to push. |
| 27 | 27 | |
| 28 | 28 | FPP is *not* a security mechanism. FPP is not intended to allow |
| 29 | 29 | untrusted individuals to push to a common repository. FPP does not |
| 30 | 30 | guarantee that no undesirable changes ever get pushed. Rather, FPP |
| 31 | -is designed as an adminstrative aid and an automatic mechanism to prevent | |
| 31 | +is designed as an administrative aid and an automatic mechanism to prevent | |
| 32 | 32 | accidents or misunderstandings. |
| 33 | 33 | |
| 34 | 34 | ## Example Use Cases |
| 35 | 35 | |
| 36 | 36 | Here are examples of the kinds of pushes that FPP is designed to prevent |
| @@ -52,40 +52,40 @@ | ||
| 52 | 52 | |
| 53 | 53 | * Do not allow tags to be added to a check-in created by a different |
| 54 | 54 | developer. |
| 55 | 55 | |
| 56 | 56 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 57 | -is suppose to detect and prevent. It is just a representative sample of | |
| 58 | -the kinds of changes FPP is intended to detect and disallow. | |
| 57 | +is intended to detect and prevent; it is just a representative sample of | |
| 58 | +the kinds of changes FPP is able to detect and disallow. | |
| 59 | 59 | |
| 60 | -Rules can be written such that they apply only to specific developers, | |
| 61 | -groups or classes of developers, or to everyone other than administrators. | |
| 60 | +Rules can be written such that they apply only to specific users, | |
| 61 | +user classes — e.g. “developer” — or to everyone other than administrators. | |
| 62 | 62 | Administrators can also be subject to FPP rules, though they have the |
| 63 | 63 | option to override. |
| 64 | 64 | |
| 65 | 65 | ## Mechanism |
| 66 | 66 | |
| 67 | 67 | FPP is a set of rules contained in a single configuration setting. |
| 68 | -The rules consist of Boolean expression and error message pairs. | |
| 69 | -At the end of each push request received by the server, all boolean | |
| 70 | -expressions are evaluated. If any boolean is true, then the push | |
| 68 | +The rules consist of paired Boolean expressions and error messages. | |
| 69 | +At the end of each push request received by the server, all | |
| 70 | +expressions are evaluated, and if any are true, the push | |
| 71 | 71 | fails with its associated error message. |
| 72 | 72 | |
| 73 | -If a push fails, the client repository must be repaired (for example | |
| 74 | -by adding tags to change the branch of check-in or to cancel a ticket | |
| 75 | -change) to fix the problem. Then the push can be retried. Fixing | |
| 76 | -FPP violations is a serious inconvenience to the developer who violated the | |
| 77 | -policy, since the violations must be fixed before *any* future push | |
| 78 | -is allowed. This inconvenience is intended to motivate the developer | |
| 73 | +If a push fails, the end user will have to repair their local repository | |
| 74 | +clone before retrying the push. For example, if the trunk branch is | |
| 75 | +protected by FPP, they can amend their commit to make it appear as the | |
| 76 | +start of a new branch off trunk, at which point the push should succeed. | |
| 77 | +This is a serious inconvenience to the developer who violated the | |
| 78 | +policy, but this is intentional, intended to motivate the developer | |
| 79 | 79 | to better follow the rules in the future. |
| 80 | 80 | |
| 81 | 81 | ## Client Side Warnings |
| 82 | 82 | |
| 83 | -FPP rules are downloaded on a "fossil clone" and on "fossil config pull fdd". | |
| 83 | +FPP rules are downloaded on a "fossil clone" and on "fossil config pull fpp". | |
| 84 | 84 | When rules exist on the client side, then certain client-side operations |
| 85 | 85 | (such as "fossil commit") |
| 86 | 86 | are also evaluated for rule violations, and appropriate warnings are issued. |
| 87 | 87 | However, for client-side operations, rules can always be overridden, since |
| 88 | 88 | the owner of the client-side clone is always administrator for their private |
| 89 | 89 | clone. Early rule check-in helps prevent the client-side repository |
| 90 | 90 | from becoming unpushable due to typos or other accidents that would have |
| 91 | 91 | caused a rule violation. |
| 92 | 92 |
| --- www/fpp.md | |
| +++ www/fpp.md | |
| @@ -7,30 +7,30 @@ | |
| 7 | ## Background |
| 8 | |
| 9 | The default behavior of Fossil is that any developer who has push |
| 10 | privileges on a repository can push any content. Project-specific |
| 11 | policy choices, such as "don't land unapproved changes on trunk" |
| 12 | or "don't reopen a closed ticket" are enforced adminstratively, not |
| 13 | by Fossil itself. Fossil maintains a detailed audit trail, so that policy |
| 14 | violations can be traced back to their source, and so that |
| 15 | violators can be duely reprimanded. Fossil also provides mechanisms |
| 16 | so that unapproved changes can be excised from critical branches without |
| 17 | deleting history. But by default, Fossil |
| 18 | does not attempt to disallow unauthorized changes from occurring in the |
| 19 | first place. |
| 20 | |
| 21 | Nothing can prevent a developer from making non-conforming and/or |
| 22 | unauthorized change in a private client-side clone of a Fossil repository, |
| 23 | as the client-side repository is under the complete control of the |
| 24 | developer who owns it. |
| 25 | Any automatic policy enforcement must happen on the common repository |
| 26 | when the developer attempts to push. |
| 27 | |
| 28 | FPP is *not* a security mechanism. FPP is not intended to allow |
| 29 | untrusted individuals to push to a common repository. FPP does not |
| 30 | guarantee that no undesirable changes ever get pushed. Rather, FPP |
| 31 | is designed as an adminstrative aid and an automatic mechanism to prevent |
| 32 | accidents or misunderstandings. |
| 33 | |
| 34 | ## Example Use Cases |
| 35 | |
| 36 | Here are examples of the kinds of pushes that FPP is designed to prevent |
| @@ -52,40 +52,40 @@ | |
| 52 | |
| 53 | * Do not allow tags to be added to a check-in created by a different |
| 54 | developer. |
| 55 | |
| 56 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 57 | is suppose to detect and prevent. It is just a representative sample of |
| 58 | the kinds of changes FPP is intended to detect and disallow. |
| 59 | |
| 60 | Rules can be written such that they apply only to specific developers, |
| 61 | groups or classes of developers, or to everyone other than administrators. |
| 62 | Administrators can also be subject to FPP rules, though they have the |
| 63 | option to override. |
| 64 | |
| 65 | ## Mechanism |
| 66 | |
| 67 | FPP is a set of rules contained in a single configuration setting. |
| 68 | The rules consist of Boolean expression and error message pairs. |
| 69 | At the end of each push request received by the server, all boolean |
| 70 | expressions are evaluated. If any boolean is true, then the push |
| 71 | fails with its associated error message. |
| 72 | |
| 73 | If a push fails, the client repository must be repaired (for example |
| 74 | by adding tags to change the branch of check-in or to cancel a ticket |
| 75 | change) to fix the problem. Then the push can be retried. Fixing |
| 76 | FPP violations is a serious inconvenience to the developer who violated the |
| 77 | policy, since the violations must be fixed before *any* future push |
| 78 | is allowed. This inconvenience is intended to motivate the developer |
| 79 | to better follow the rules in the future. |
| 80 | |
| 81 | ## Client Side Warnings |
| 82 | |
| 83 | FPP rules are downloaded on a "fossil clone" and on "fossil config pull fdd". |
| 84 | When rules exist on the client side, then certain client-side operations |
| 85 | (such as "fossil commit") |
| 86 | are also evaluated for rule violations, and appropriate warnings are issued. |
| 87 | However, for client-side operations, rules can always be overridden, since |
| 88 | the owner of the client-side clone is always administrator for their private |
| 89 | clone. Early rule check-in helps prevent the client-side repository |
| 90 | from becoming unpushable due to typos or other accidents that would have |
| 91 | caused a rule violation. |
| 92 |
| --- www/fpp.md | |
| +++ www/fpp.md | |
| @@ -7,30 +7,30 @@ | |
| 7 | ## Background |
| 8 | |
| 9 | The default behavior of Fossil is that any developer who has push |
| 10 | privileges on a repository can push any content. Project-specific |
| 11 | policy choices, such as "don't land unapproved changes on trunk" |
| 12 | or "don't reopen a closed ticket" are enforced administratively, not |
| 13 | by Fossil itself. Fossil maintains a detailed audit trail so that policy |
| 14 | violations can be traced back to their source, and so that |
| 15 | violators can be duly reprimanded. Fossil also provides mechanisms |
| 16 | so that unapproved changes can be excised from critical branches without |
| 17 | deleting history. But by default, Fossil |
| 18 | does not attempt to disallow unauthorized changes from occurring in the |
| 19 | first place. |
| 20 | |
| 21 | Nothing can prevent a developer from making non-conforming and/or |
| 22 | unauthorized change in a private client-side clone of a Fossil repository |
| 23 | since the client-side repository is under the complete control of the |
| 24 | developer who owns it. |
| 25 | Any automatic policy enforcement must happen on the common repository |
| 26 | when the developer attempts to push. |
| 27 | |
| 28 | FPP is *not* a security mechanism. FPP is not intended to allow |
| 29 | untrusted individuals to push to a common repository. FPP does not |
| 30 | guarantee that no undesirable changes ever get pushed. Rather, FPP |
| 31 | is designed as an administrative aid and an automatic mechanism to prevent |
| 32 | accidents or misunderstandings. |
| 33 | |
| 34 | ## Example Use Cases |
| 35 | |
| 36 | Here are examples of the kinds of pushes that FPP is designed to prevent |
| @@ -52,40 +52,40 @@ | |
| 52 | |
| 53 | * Do not allow tags to be added to a check-in created by a different |
| 54 | developer. |
| 55 | |
| 56 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 57 | is intended to detect and prevent; it is just a representative sample of |
| 58 | the kinds of changes FPP is able to detect and disallow. |
| 59 | |
| 60 | Rules can be written such that they apply only to specific users, |
| 61 | user classes — e.g. “developer” — or to everyone other than administrators. |
| 62 | Administrators can also be subject to FPP rules, though they have the |
| 63 | option to override. |
| 64 | |
| 65 | ## Mechanism |
| 66 | |
| 67 | FPP is a set of rules contained in a single configuration setting. |
| 68 | The rules consist of paired Boolean expressions and error messages. |
| 69 | At the end of each push request received by the server, all |
| 70 | expressions are evaluated, and if any are true, the push |
| 71 | fails with its associated error message. |
| 72 | |
| 73 | If a push fails, the end user will have to repair their local repository |
| 74 | clone before retrying the push. For example, if the trunk branch is |
| 75 | protected by FPP, they can amend their commit to make it appear as the |
| 76 | start of a new branch off trunk, at which point the push should succeed. |
| 77 | This is a serious inconvenience to the developer who violated the |
| 78 | policy, but this is intentional, intended to motivate the developer |
| 79 | to better follow the rules in the future. |
| 80 | |
| 81 | ## Client Side Warnings |
| 82 | |
| 83 | FPP rules are downloaded on a "fossil clone" and on "fossil config pull fpp". |
| 84 | When rules exist on the client side, then certain client-side operations |
| 85 | (such as "fossil commit") |
| 86 | are also evaluated for rule violations, and appropriate warnings are issued. |
| 87 | However, for client-side operations, rules can always be overridden, since |
| 88 | the owner of the client-side clone is always administrator for their private |
| 89 | clone. Early rule check-in helps prevent the client-side repository |
| 90 | from becoming unpushable due to typos or other accidents that would have |
| 91 | caused a rule violation. |
| 92 |