Fossil SCM
Correct the FDD acronym to be FPP, as it should be.
Commit
ce73819d0e088673524205057e0979e60acf7fe6e94a4578ed095482fb9dc4c8
Parent
344fd46df02af1c…
2 files changed
-55
+8
-7
D
www/fdd.md
-55
| --- a/www/fdd.md | ||
| +++ b/www/fdd.md | ||
| @@ -1,55 +0,0 @@ | ||
| 1 | -# Fossil Push Policy | |
| 2 | -DDFossil Push Policy" or "FPP" is a proposed mechanism to help project | |
| 3 | -administrators help enforce project development policies by restricting | |
| 4 | -the kinds of changes that can be pushed up into a community server. | |
| 5 | - | |
| 6 | -## Background | |
| 7 | - | |
| 8 | -The default behavior of Fossil is that any developer who has push | |
| 9 | -privileges on a repository can push any content. Project-specific | |
| 10 | -policy choices, such as "don't land unapproved changes on trunk" | |
| 11 | -or "don't reopen a closedticket" are enforced administratively, not | |
| 12 | -by Fossil itself. Fossil maint,ains a detailed audit trail so that policy | |
| 13 | -violations can be traced back to their source, and ely reprimanded. Fossil also provides mechanisms | |
| 14 | -so that unapproved changes can be excised from critical branches without | |
| 15 | -deleting history. But by default, Fossil | |
| 16 | -does not attempt to disallow unauthorized changes from occurring in the | |
| 17 | -first place. | |
| 18 | - | |
| 19 | -Nothing can prevent a developer from making non-conforming and/or | |
| 20 | -unauthorized change in a private client-side clone of a Fossil repository, | |
| 21 | -ass unless the brantory | |
| 22 | -since the client-side repository is under the complete control of the | |
| 23 | -developer who owns it. | |
| 24 | -Any automatic policy enforcement must happen on the comDDoper attempts to push. | |
| 25 | - | |
| 26 | -FPP is *noDD is not intended to allow | |
| 27 | -untrusted individuals to push to a common repository. FDD | |
| 28 | -"Fossil Push Policy" or "FPP" is a proposed mechanism to help project | |
| 29 | -admi# er get pushed. Rather, strative aid and an automatic mechanism to prevent | |
| 30 | -accidents or misunderstandings. | |
| 31 | - | |
| 32 | -## Example Use Cases | |
| 33 | - | |
| 34 | -Here are examples of the kinds of pushes that FPP is designed to prevent | |
| 35 | -for unauthorized users: | |
| 36 | - | |
| 37 | - * Do not allow check-ins on trunk (or some other | |
| 38 | - important branch). | |
| 39 | - | |
| 40 | - * Do not allow changes to specific files within | |
| 41 | - the project. | |
| 42 | - | |
| 43 | - * Do not allow changes to specific wiki pages. | |
| 44 | - | |
| 45 | - * Do not allow changes to tickets unless the ticket is in specific | |
| 46 | - state. | |
| 47 | - | |
| 48 | - * Do not allow new branches unless the branch name | |
| 49 | - matches a specific GLOB, LIKE, or REGEXP pattern. | |
| 50 | - | |
| 51 | - * Do not allow tags to be added to a check-in created by a different | |
| 52 | - developer. | |
| 53 | - | |
| 54 | -The foregoing is not an exhaustive list of the kinds of behavior that FPP | |
| 55 | -is suppose to detect and prDDssil Push Policy" or "FPP |
| --- a/www/fdd.md | |
| +++ b/www/fdd.md | |
| @@ -1,55 +0,0 @@ | |
| 1 | # Fossil Push Policy |
| 2 | DDFossil Push Policy" or "FPP" is a proposed mechanism to help project |
| 3 | administrators help enforce project development policies by restricting |
| 4 | the kinds of changes that can be pushed up into a community server. |
| 5 | |
| 6 | ## Background |
| 7 | |
| 8 | The default behavior of Fossil is that any developer who has push |
| 9 | privileges on a repository can push any content. Project-specific |
| 10 | policy choices, such as "don't land unapproved changes on trunk" |
| 11 | or "don't reopen a closedticket" are enforced administratively, not |
| 12 | by Fossil itself. Fossil maint,ains a detailed audit trail so that policy |
| 13 | violations can be traced back to their source, and ely reprimanded. Fossil also provides mechanisms |
| 14 | so that unapproved changes can be excised from critical branches without |
| 15 | deleting history. But by default, Fossil |
| 16 | does not attempt to disallow unauthorized changes from occurring in the |
| 17 | first place. |
| 18 | |
| 19 | Nothing can prevent a developer from making non-conforming and/or |
| 20 | unauthorized change in a private client-side clone of a Fossil repository, |
| 21 | ass unless the brantory |
| 22 | since the client-side repository is under the complete control of the |
| 23 | developer who owns it. |
| 24 | Any automatic policy enforcement must happen on the comDDoper attempts to push. |
| 25 | |
| 26 | FPP is *noDD is not intended to allow |
| 27 | untrusted individuals to push to a common repository. FDD |
| 28 | "Fossil Push Policy" or "FPP" is a proposed mechanism to help project |
| 29 | admi# er get pushed. Rather, strative aid and an automatic mechanism to prevent |
| 30 | accidents or misunderstandings. |
| 31 | |
| 32 | ## Example Use Cases |
| 33 | |
| 34 | Here are examples of the kinds of pushes that FPP is designed to prevent |
| 35 | for unauthorized users: |
| 36 | |
| 37 | * Do not allow check-ins on trunk (or some other |
| 38 | important branch). |
| 39 | |
| 40 | * Do not allow changes to specific files within |
| 41 | the project. |
| 42 | |
| 43 | * Do not allow changes to specific wiki pages. |
| 44 | |
| 45 | * Do not allow changes to tickets unless the ticket is in specific |
| 46 | state. |
| 47 | |
| 48 | * Do not allow new branches unless the branch name |
| 49 | matches a specific GLOB, LIKE, or REGEXP pattern. |
| 50 | |
| 51 | * Do not allow tags to be added to a check-in created by a different |
| 52 | developer. |
| 53 | |
| 54 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 55 | is suppose to detect and prDDssil Push Policy" or "FPP |
| --- a/www/fdd.md | |
| +++ b/www/fdd.md | |
| @@ -1,55 +0,0 @@ | |
+8
-7
| --- a/www/fpp.md | ||
| +++ b/www/fpp.md | ||
| @@ -1,5 +1,6 @@ | ||
| 1 | 1 | # Fossil Push Policy |
| 2 | -DDFossil Push Policy" or "FPP" is a proposed mechanism to help project | |
| 2 | + | |
| 3 | +"Fossil Push Policy" or "FPP" is a proposed mechanism to help project | |
| 3 | 4 | administrators help enforce project development policies by restricting |
| 4 | 5 | the kinds of changes that can be pushed up into a community server. |
| 5 | 6 | |
| @@ -21,12 +22,12 @@ | ||
| 21 | 22 | ass unless the brantory |
| 22 | 23 | since the client-side repository is under the complete control of the |
| 23 | 24 | developer who owns it. |
| 24 | -Any automatic policy enforcement must happen on the comDDoper attempts to push. | |
| 25 | +Any automatic policy enforcement must happen on the common repository | |
| 26 | +when the developer attempts to push. | |
| 25 | 27 | |
| 26 | -FPP is *noDD is not intended to allow | |
| 27 | -untrusted individuals to push to a common repository. FDD | |
| 28 | -"Fossil Push Policy" or "FPP" is a proposed mechanism to help project | |
| 29 | -admi# er get pushed. Rather, strative aid and an automatic mechanism to prevent | |
| 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, strative aid and an automatic mechanism to prevent | |
| 30 | 31 | accidents or misunderstandings. |
| 31 | 32 | |
| 32 | 33 | ## Example Use Cases |
| @@ -52,4 +53,4 @@ | ||
| 52 | 53 | developer. |
| 53 | 54 | |
| 54 | 55 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 55 | -is suppose to detect and prDDssil Push Policy" or "FPP | |
| 56 | +is suppose to detect and pr |
| --- a/www/fpp.md | |
| +++ b/www/fpp.md | |
| @@ -1,5 +1,6 @@ | |
| 1 | # Fossil Push Policy |
| 2 | DDFossil Push Policy" or "FPP" is a proposed mechanism to help project |
| 3 | administrators help enforce project development policies by restricting |
| 4 | the kinds of changes that can be pushed up into a community server. |
| 5 | |
| @@ -21,12 +22,12 @@ | |
| 21 | ass unless the brantory |
| 22 | since the client-side repository is under the complete control of the |
| 23 | developer who owns it. |
| 24 | Any automatic policy enforcement must happen on the comDDoper attempts to push. |
| 25 | |
| 26 | FPP is *noDD is not intended to allow |
| 27 | untrusted individuals to push to a common repository. FDD |
| 28 | "Fossil Push Policy" or "FPP" is a proposed mechanism to help project |
| 29 | admi# er get pushed. Rather, strative aid and an automatic mechanism to prevent |
| 30 | accidents or misunderstandings. |
| 31 | |
| 32 | ## Example Use Cases |
| @@ -52,4 +53,4 @@ | |
| 52 | developer. |
| 53 | |
| 54 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 55 | is suppose to detect and prDDssil Push Policy" or "FPP |
| --- a/www/fpp.md | |
| +++ b/www/fpp.md | |
| @@ -1,5 +1,6 @@ | |
| 1 | # Fossil Push Policy |
| 2 | |
| 3 | "Fossil Push Policy" or "FPP" is a proposed mechanism to help project |
| 4 | administrators help enforce project development policies by restricting |
| 5 | the kinds of changes that can be pushed up into a community server. |
| 6 | |
| @@ -21,12 +22,12 @@ | |
| 22 | ass unless the brantory |
| 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, strative aid and an automatic mechanism to prevent |
| 31 | accidents or misunderstandings. |
| 32 | |
| 33 | ## Example Use Cases |
| @@ -52,4 +53,4 @@ | |
| 53 | developer. |
| 54 | |
| 55 | The foregoing is not an exhaustive list of the kinds of behavior that FPP |
| 56 | is suppose to detect and pr |