Re: [RFC] Implementing obliterate as a node-rev-id blacklist

Philip Martin wrote:
> I was wondering whether it would be possible to implement Julian's dd1
> model of obliterate, where obliterate causes file and directory nodes
> to be removed from the history, as a node-rev-id blacklist.  Rather
> than have obliterate modify history by rewriting previous revisions
> libsvn_repos would simply add the obliterated nodes to a blacklist,
> with storage provided by the fs layer, and then libsvn_repos would
> query the blacklist before sending out node information.  Think of it
> as a path based auth system built into libsvn_repos.

Hi Philip. Thanks for the thoughts. I discussed this idea here:
<http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402573>, and this reply from Brane is probably the most interesting place to dig in: <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402654>.

- Julian


> One advantage of doing it this way would be that, apart from some
> relatively simple fs storage/query stuff, the clever bits all happen
> at the repos level and so only have to be implemented once to get both
> FSFS and BDB implementations.
> 
> One disadvantage is that the querying would add some overhead to all
> repos operations, although we could probably arrange for this to be
> minimal on repositories that are configured not to support
> obliteration.
> 
> One feature that could be viewed as either an advantage or a
> disadvantage is that obliteration could even be reversible.  Removing
> a blacklisted node-rev-id from the blacklist would "unobliterate" it.
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2429170

Please start new threads on the <[email protected]> mailing list.
To subscribe to the new list, send an empty e-mail to <[email protected]>.