Going the full way with the "obliterate" feature, i.e. permanently delete a file version and recursively spread this deletion like a virus upon sync, is not certainly a feature we would be comfortable with, as the would be quite a lot of issues regarding trust ("oh, the remote server states I should delete this, and who is he to say that? I only trust about myself"). OTOH we could probably use a strictly local "forbid" feature such as this: mtn forbid VERSION or, more conveniently, mtn forbid -r REVISION FILENAME that would add VERSION to a table of "forbidden versions" and delete it from the file content table (changing the "base" of the next deltas to apply on the previous not-forbidden file content). On sync, any forbidden VERSION received would be silently dropped. On checkout/update, it should not panic with a missing content but instead loudly say "File 'xyz' not updated because his content was forbidden.".
I also have another (debatable) use-case that is not related to legally encumbered content you are told "from above" you must delete: someone using monotone and his wonderful binary-content support to help deploying and updating an installed software (i.e. executables!). If one specific version of the executable has got a virus, people from the security team may well decide that is is better to entirely forbid that content, thus avoiding other people from executing them and thus infecting their system (and possibly many more executables). Once policies are here, instead of a "forbidden contents table" it could certainly be useful (better?) to have a sort of "CRL" for VERSIONs (only, instead of a "certificate revocation list" it would be a "content removal list") signed by the very same people that have signed the policy. After all people can't (and shouldn't) be able to delete your local content (and you can do read-only backups anyway, if you want, so that's really pointless) but if you want to work on a project you should probably accept his policies, including not getting 'em in trouble because you're committing a new revision containing old forbidden content with only a whitespace change (you can do that anyway, of course, but having to accept the CRL as part of the policy itself doesn't seem too much controversial to me). What do you think? What possible problems do you foresee that I didn't think of? (please think about the "base" strictly local-only "forbidden list" and the policy-based, and thus distributed, CRL thing separately, on reply, as they are certainly two very different beasts) Lapo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel