On Thu, May 31, 2018 at 10:51 PM, Eugene MIndrov <eugene.mind...@yandex.ru> wrote:
> Now, if it was against the implementation then it wouldn't have been > implemented, right? > It was implemented only as a last resort, not for daily use. The very real use case that "needs" to be supported by this feature is that someone commits copyrighted material into someone else's repo. if i were to make a copy of copyrighted ebook and post it as an attachment to someone's fossil wiki, the owner of that wiki _needs_ (for legal reasons) to be able to banish it. Shunning was not one of Fossil's original features - it was added to enable that sort of worst-case scenario. > The main reason I haven't used shun for my purposes is the attachment I > was trying to nuke was taking 90% of the entire repo and shun leaves > shunned artifacts lying around, just adding their SHA into the shun list so > they would be excluded from sync operations. > That's not true: see the very first sentence the documentation of the shun page: "A shunned artifact will not be pushed nor accepted in a pull and the artifact content will be purged from the repository the next time the repository is rebuilt." You simply need to rebuild the repo after shunning. That won't eliminate it from any closes, but it will keep them from re-synching it back to your copy. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
