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 <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.
Received on 2009-12-10 13:24:42 CET