Fossil SCM
Added "Alternatives" section to shunning.wiki.
Commit
004c5507247702b8d89c907c3377207b199b6d37852f99a9ac3aceb73259f12b
Parent
b3e8253d78e14ba…
1 file changed
+81
-17
+81
-17
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -1,26 +1,90 @@ | ||
| 1 | 1 | <title>Deleting Content From Fossil</title> |
| 2 | -<h1 align="center">Deleting Content From Fossil</h1> | |
| 2 | + | |
| 3 | +<h2>Good Reasons for Removing Content from a Fossil Repository</h2> | |
| 3 | 4 | |
| 4 | -Fossil is designed to keep all historical content forever. Users | |
| 5 | -of Fossil are discouraged from "deleting" content simply because it | |
| 6 | -has become obsolete. Old content is part of the historical record | |
| 7 | -(part of the "fossil record") and should be maintained indefinitely. | |
| 8 | -Such is the design intent of Fossil. | |
| 5 | +Fossil is designed to keep all historical content forever. Fossil | |
| 6 | +purposely makes it difficult for users to delete content. Old content | |
| 7 | +is part of the project's <i>*ahem*</i> fossil record and should be | |
| 8 | +maintained indefinitely to maintain an accurate history of the project. | |
| 9 | 9 | |
| 10 | 10 | Nevertheless, there may occasionally arise legitimate reasons for |
| 11 | -deleting content. Such reasons might include: | |
| 12 | - | |
| 13 | - * Spammers have inserted inappropriate content into a wiki page | |
| 14 | - or ticket that needs to be removed. | |
| 15 | - | |
| 16 | - * A file that contains trade secrets or that is under copyright | |
| 17 | - may have been accidentally committed and needs to be backed | |
| 18 | - out. | |
| 19 | - | |
| 20 | - * A malformed control artifact may have been inserted and is | |
| 21 | - disrupting the operation of Fossil. | |
| 11 | +deleting content. Such reasons include: | |
| 12 | + | |
| 13 | + * Spammers inserted inappropriate content into a wiki page, forum post, | |
| 14 | + or ticket. Fossil lets you easily hide or amend such content, but | |
| 15 | + since it is not a legitimate part of the project's history, there | |
| 16 | + is no value in keeping it, so it is best removed permanently. | |
| 17 | + | |
| 18 | + * A file that contains trade secrets or that is under someone else's | |
| 19 | + copyright was accidentally committed and needs to be backed out. | |
| 20 | + | |
| 21 | + * A malformed control artifact was inserted and is disrupting the | |
| 22 | + operation of Fossil. | |
| 23 | + | |
| 24 | + | |
| 25 | +<h2>Alternatives</h2> | |
| 26 | + | |
| 27 | +All of these are rare cases: Fossil is [./antibot.wiki | designed to | |
| 28 | +foil spammers up front], legally problematic check-ins should range from | |
| 29 | +rare to nonexistent, and you have to go way out of your way to force | |
| 30 | +Fossil to insert bad control artifacts. Therefore, before we get to | |
| 31 | +methods of permanently deleting content from a Fossil repos, let's give | |
| 32 | +some alternatives that usually suffice, which don't damage the project's | |
| 33 | +fossil record: | |
| 34 | + | |
| 35 | +<ul> | |
| 36 | + <li><p>When a forum post or wiki article is "deleted," what actually | |
| 37 | + happens is that a new empty version is added to the Fossil | |
| 38 | + [./blockchain.md | block chain]. The web interface interprets this | |
| 39 | + as "deleted," but the prior version remains available if you go | |
| 40 | + digging for it.</p></li> | |
| 41 | + | |
| 42 | + <li><p>When you close a ticket, it's marked in a way that causes it | |
| 43 | + to not show up in the normal ticket reports. You usually want to | |
| 44 | + give it a Resolution such as "Rejected" when this happens, plus | |
| 45 | + possibly a comment explaining why you're closing it. This is all new | |
| 46 | + information added to the ticket, not deletion.</p></li> | |
| 47 | + | |
| 48 | + <li><p>When you <tt>fossil rm</tt> a file, a new manifest is | |
| 49 | + checked into the repository with the same file list as for the prior | |
| 50 | + version minus the "removed" file. The file is still present in the | |
| 51 | + repository; it just isn't part of that version forward on that | |
| 52 | + branch.</p></li> | |
| 53 | + | |
| 54 | + <li><p>If you make a bad check-in, you can shunt it off to the side | |
| 55 | + by amending it to put it on a different branch, then continuing | |
| 56 | + development on the prior branch: | |
| 57 | + <p> | |
| 58 | + <tt>$ fossil amend abcd1234 --branch BOGUS --hide<br> | |
| 59 | + $ fossil up trunk</tt> | |
| 60 | + <p> | |
| 61 | + The first command moves check-in ID <tt>abcd1234</tt> (and any | |
| 62 | + subsequent check-ins on that branch!) to a branch called | |
| 63 | + <tt>BOGUS</tt>, then hides it so it doesn't show up on the | |
| 64 | + timeline. You can call this branch anything you like, and you can | |
| 65 | + re-use the same name as many times as you like. No content is | |
| 66 | + actually deleted: it's just shunted off to the side and hidden away. | |
| 67 | + You might find it easier to do this from the Fossil web UI in | |
| 68 | + the "edit" function for a check-in. | |
| 69 | + <p> | |
| 70 | + The second command returns to the last good check-in on that branch | |
| 71 | + so you can continue work from that point.</p></li> | |
| 72 | + | |
| 73 | + <li><p>When the check-in you want to remove is followed by good | |
| 74 | + check-ins on the same branch, you can't use the previous method, | |
| 75 | + because it will move the good check-ins, too. The solution is: | |
| 76 | + <p> | |
| 77 | + <tt>$ fossil merge --backout abcd1234</tt> | |
| 78 | + <p>That creates a diff in the check-out directory that backs out the | |
| 79 | + bad check-in <tt>abcd1234</tt>. You then fix up any merge conflicts, | |
| 80 | + build, test, etc., then check the reverting change into the | |
| 81 | + repository. Again, nothing is actually deleted; you're just adding | |
| 82 | + more information to the repository which corrects a prior | |
| 83 | + check-in.</p></li> | |
| 84 | +</ul> | |
| 85 | + | |
| 22 | 86 | |
| 23 | 87 | <h2>Shunning</h2> |
| 24 | 88 | |
| 25 | 89 | Fossil provides a mechanism called "shunning" for removing content from |
| 26 | 90 | a repository. |
| 27 | 91 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -1,26 +1,90 @@ | |
| 1 | <title>Deleting Content From Fossil</title> |
| 2 | <h1 align="center">Deleting Content From Fossil</h1> |
| 3 | |
| 4 | Fossil is designed to keep all historical content forever. Users |
| 5 | of Fossil are discouraged from "deleting" content simply because it |
| 6 | has become obsolete. Old content is part of the historical record |
| 7 | (part of the "fossil record") and should be maintained indefinitely. |
| 8 | Such is the design intent of Fossil. |
| 9 | |
| 10 | Nevertheless, there may occasionally arise legitimate reasons for |
| 11 | deleting content. Such reasons might include: |
| 12 | |
| 13 | * Spammers have inserted inappropriate content into a wiki page |
| 14 | or ticket that needs to be removed. |
| 15 | |
| 16 | * A file that contains trade secrets or that is under copyright |
| 17 | may have been accidentally committed and needs to be backed |
| 18 | out. |
| 19 | |
| 20 | * A malformed control artifact may have been inserted and is |
| 21 | disrupting the operation of Fossil. |
| 22 | |
| 23 | <h2>Shunning</h2> |
| 24 | |
| 25 | Fossil provides a mechanism called "shunning" for removing content from |
| 26 | a repository. |
| 27 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -1,26 +1,90 @@ | |
| 1 | <title>Deleting Content From Fossil</title> |
| 2 | |
| 3 | <h2>Good Reasons for Removing Content from a Fossil Repository</h2> |
| 4 | |
| 5 | Fossil is designed to keep all historical content forever. Fossil |
| 6 | purposely makes it difficult for users to delete content. Old content |
| 7 | is part of the project's <i>*ahem*</i> fossil record and should be |
| 8 | maintained indefinitely to maintain an accurate history of the project. |
| 9 | |
| 10 | Nevertheless, there may occasionally arise legitimate reasons for |
| 11 | deleting content. Such reasons include: |
| 12 | |
| 13 | * Spammers inserted inappropriate content into a wiki page, forum post, |
| 14 | or ticket. Fossil lets you easily hide or amend such content, but |
| 15 | since it is not a legitimate part of the project's history, there |
| 16 | is no value in keeping it, so it is best removed permanently. |
| 17 | |
| 18 | * A file that contains trade secrets or that is under someone else's |
| 19 | copyright was accidentally committed and needs to be backed out. |
| 20 | |
| 21 | * A malformed control artifact was inserted and is disrupting the |
| 22 | operation of Fossil. |
| 23 | |
| 24 | |
| 25 | <h2>Alternatives</h2> |
| 26 | |
| 27 | All of these are rare cases: Fossil is [./antibot.wiki | designed to |
| 28 | foil spammers up front], legally problematic check-ins should range from |
| 29 | rare to nonexistent, and you have to go way out of your way to force |
| 30 | Fossil to insert bad control artifacts. Therefore, before we get to |
| 31 | methods of permanently deleting content from a Fossil repos, let's give |
| 32 | some alternatives that usually suffice, which don't damage the project's |
| 33 | fossil record: |
| 34 | |
| 35 | <ul> |
| 36 | <li><p>When a forum post or wiki article is "deleted," what actually |
| 37 | happens is that a new empty version is added to the Fossil |
| 38 | [./blockchain.md | block chain]. The web interface interprets this |
| 39 | as "deleted," but the prior version remains available if you go |
| 40 | digging for it.</p></li> |
| 41 | |
| 42 | <li><p>When you close a ticket, it's marked in a way that causes it |
| 43 | to not show up in the normal ticket reports. You usually want to |
| 44 | give it a Resolution such as "Rejected" when this happens, plus |
| 45 | possibly a comment explaining why you're closing it. This is all new |
| 46 | information added to the ticket, not deletion.</p></li> |
| 47 | |
| 48 | <li><p>When you <tt>fossil rm</tt> a file, a new manifest is |
| 49 | checked into the repository with the same file list as for the prior |
| 50 | version minus the "removed" file. The file is still present in the |
| 51 | repository; it just isn't part of that version forward on that |
| 52 | branch.</p></li> |
| 53 | |
| 54 | <li><p>If you make a bad check-in, you can shunt it off to the side |
| 55 | by amending it to put it on a different branch, then continuing |
| 56 | development on the prior branch: |
| 57 | <p> |
| 58 | <tt>$ fossil amend abcd1234 --branch BOGUS --hide<br> |
| 59 | $ fossil up trunk</tt> |
| 60 | <p> |
| 61 | The first command moves check-in ID <tt>abcd1234</tt> (and any |
| 62 | subsequent check-ins on that branch!) to a branch called |
| 63 | <tt>BOGUS</tt>, then hides it so it doesn't show up on the |
| 64 | timeline. You can call this branch anything you like, and you can |
| 65 | re-use the same name as many times as you like. No content is |
| 66 | actually deleted: it's just shunted off to the side and hidden away. |
| 67 | You might find it easier to do this from the Fossil web UI in |
| 68 | the "edit" function for a check-in. |
| 69 | <p> |
| 70 | The second command returns to the last good check-in on that branch |
| 71 | so you can continue work from that point.</p></li> |
| 72 | |
| 73 | <li><p>When the check-in you want to remove is followed by good |
| 74 | check-ins on the same branch, you can't use the previous method, |
| 75 | because it will move the good check-ins, too. The solution is: |
| 76 | <p> |
| 77 | <tt>$ fossil merge --backout abcd1234</tt> |
| 78 | <p>That creates a diff in the check-out directory that backs out the |
| 79 | bad check-in <tt>abcd1234</tt>. You then fix up any merge conflicts, |
| 80 | build, test, etc., then check the reverting change into the |
| 81 | repository. Again, nothing is actually deleted; you're just adding |
| 82 | more information to the repository which corrects a prior |
| 83 | check-in.</p></li> |
| 84 | </ul> |
| 85 | |
| 86 | |
| 87 | <h2>Shunning</h2> |
| 88 | |
| 89 | Fossil provides a mechanism called "shunning" for removing content from |
| 90 | a repository. |
| 91 |