You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2009/12/09 22:27:05 UTC
[RFC] Implementing obliterate as a node-rev-id blacklist
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.
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.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2429030
Please start new threads on the <de...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <de...@subversion.apache.org>.
Re: [RFC] Implementing obliterate as a node-rev-id blacklist
Posted by Carsten Koch <Ca...@web.de>.
On Wed, 2009-12-09 at 22:27 +0000, Philip Martin wrote:
...
> 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.
Those people who want obliterate so they can reclaim
the space of inadvertently committed huge files and
those people who want obliterate so they can reliably
destroy inadvertently committed secret documents may
consider this more than a disadvantage.
Cheers,
Carsten.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2429033
Please start new threads on the <de...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <de...@subversion.apache.org>.
Re: [RFC] Implementing obliterate as a node-rev-id blacklist
Posted by Julian Foad <ju...@btopenworld.com>.
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 <de...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <de...@subversion.apache.org>.
Re: [RFC] Implementing obliterate as a node-rev-id blacklist
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
> 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.
>
I think what you describe is more like a repos-level path+revision-based
authorization system. Which IMHO is a good thing to have, and could be
used as an alternative to obliterate where actual space reclamation is
not an issue. But don't think this would be a much quicker way to
acheive what Julian is already doing at the txn level; for one thing,
the "storage provided by the FS layer" bit sounds simple, but implies an
FS version change which is always less than trivial to deal with. The
beauty of Julian's transaction-based obliteration is that it doesn't
require any change in the FS schema (even though it will be quite hairy
to do in FSFS which is mostly write-once).
-- Brane