Fossil SCM
Clarify the documentation on shunning happening automatically by default on a "pull" operation.
Commit
03f0317c798211256b412277937d3db9514316c8
Parent
c11f57fa489e1b4…
1 file changed
+7
-4
+7
-4
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -34,32 +34,35 @@ | ||
| 34 | 34 | "rebuild" command. |
| 35 | 35 | |
| 36 | 36 | <h3>Shunning lists are local state</h3> |
| 37 | 37 | |
| 38 | 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | -In other words, shunning does not propagate using the normal "sync" | |
| 40 | -mechanism. An artifact can be | |
| 39 | +In other words, shunning does not propagate to a remote repository | |
| 40 | +using the normal "sync" mechanism. An artifact can be | |
| 41 | 41 | shunned from one repository but be allowed to exist in another. The fact that |
| 42 | 42 | the shunning list does not propagate is a security feature. If the |
| 43 | 43 | shunning list propagated then a malicious user (or |
| 44 | 44 | a bug in the fossil code) might introduce a shun record that would |
| 45 | 45 | propagate through all repositories in a network and permanently |
| 46 | 46 | destroy vital information. By refusing to propagate the shunning list, |
| 47 | 47 | Fossil insures that no remote user will ever be able to remove |
| 48 | 48 | information from your personal repositories without your permission. |
| 49 | 49 | |
| 50 | -The shunning list does not propagate by the normal "sync" mechanism, | |
| 50 | +The shunning list does not propagate to a remote repository | |
| 51 | +by the normal "sync" mechanism, | |
| 51 | 52 | but it is still possible to copy shuns from one repository to another |
| 52 | 53 | using the "configuration" command: |
| 53 | 54 | |
| 54 | 55 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 55 | 56 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 56 | 57 | |
| 57 | 58 | The two command above will pull or push shunning lists from or to |
| 58 | 59 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 59 | 60 | end. "Admin" privilege on the remote server is required in order to |
| 60 | -push a shun list. | |
| 61 | +push a shun list. In contrast, the shunning list will be automatically | |
| 62 | +received by default as part of a normal client "pull" operation unless | |
| 63 | +disabled by the "<tt>auto-shun</tt>" setting. | |
| 61 | 64 | |
| 62 | 65 | Note that the shunning list remains in the repository even after the |
| 63 | 66 | shunned artifact has been removed. This is to prevent the artifact |
| 64 | 67 | from being reintroduced into the repository the next time it syncs with |
| 65 | 68 | another repository that has not shunned the artifact. |
| 66 | 69 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -34,32 +34,35 @@ | |
| 34 | "rebuild" command. |
| 35 | |
| 36 | <h3>Shunning lists are local state</h3> |
| 37 | |
| 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | In other words, shunning does not propagate using the normal "sync" |
| 40 | mechanism. An artifact can be |
| 41 | shunned from one repository but be allowed to exist in another. The fact that |
| 42 | the shunning list does not propagate is a security feature. If the |
| 43 | shunning list propagated then a malicious user (or |
| 44 | a bug in the fossil code) might introduce a shun record that would |
| 45 | propagate through all repositories in a network and permanently |
| 46 | destroy vital information. By refusing to propagate the shunning list, |
| 47 | Fossil insures that no remote user will ever be able to remove |
| 48 | information from your personal repositories without your permission. |
| 49 | |
| 50 | The shunning list does not propagate by the normal "sync" mechanism, |
| 51 | but it is still possible to copy shuns from one repository to another |
| 52 | using the "configuration" command: |
| 53 | |
| 54 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 55 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 56 | |
| 57 | The two command above will pull or push shunning lists from or to |
| 58 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 59 | end. "Admin" privilege on the remote server is required in order to |
| 60 | push a shun list. |
| 61 | |
| 62 | Note that the shunning list remains in the repository even after the |
| 63 | shunned artifact has been removed. This is to prevent the artifact |
| 64 | from being reintroduced into the repository the next time it syncs with |
| 65 | another repository that has not shunned the artifact. |
| 66 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -34,32 +34,35 @@ | |
| 34 | "rebuild" command. |
| 35 | |
| 36 | <h3>Shunning lists are local state</h3> |
| 37 | |
| 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | In other words, shunning does not propagate to a remote repository |
| 40 | using the normal "sync" mechanism. An artifact can be |
| 41 | shunned from one repository but be allowed to exist in another. The fact that |
| 42 | the shunning list does not propagate is a security feature. If the |
| 43 | shunning list propagated then a malicious user (or |
| 44 | a bug in the fossil code) might introduce a shun record that would |
| 45 | propagate through all repositories in a network and permanently |
| 46 | destroy vital information. By refusing to propagate the shunning list, |
| 47 | Fossil insures that no remote user will ever be able to remove |
| 48 | information from your personal repositories without your permission. |
| 49 | |
| 50 | The shunning list does not propagate to a remote repository |
| 51 | by the normal "sync" mechanism, |
| 52 | but it is still possible to copy shuns from one repository to another |
| 53 | using the "configuration" command: |
| 54 | |
| 55 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 56 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 57 | |
| 58 | The two command above will pull or push shunning lists from or to |
| 59 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 60 | end. "Admin" privilege on the remote server is required in order to |
| 61 | push a shun list. In contrast, the shunning list will be automatically |
| 62 | received by default as part of a normal client "pull" operation unless |
| 63 | disabled by the "<tt>auto-shun</tt>" setting. |
| 64 | |
| 65 | Note that the shunning list remains in the repository even after the |
| 66 | shunned artifact has been removed. This is to prevent the artifact |
| 67 | from being reintroduced into the repository the next time it syncs with |
| 68 | another repository that has not shunned the artifact. |
| 69 |