[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Two approaches to data-hiding (for obliterate)

From: Branko Cibej <brane_at_xbc.nu>
Date: Thu, 01 Oct 2009 21:12:45 +0200

Julian Foad wrote:
> On Thu, 2009-10-01 at 19:16 +0200, Branko Cibej wrote:
>> Julian Foad wrote:
>>> I'm thinking about the data-hiding part of "obliterate".
>>> Example: obliterate (hide) /path/to/foo in revision 50.
>>> * Approach 1:
>>> Edit the FS in the database: replace the old revision 50 with a new
>>> transaction that's mostly the same except doesn't have an entry for
>>> "foo" in its "/dir/to" directory node. "Commit" the new transaction in
>>> place of revision 50, adjusting all links that pointed to the old
>>> revision 50 to point to the new one instead.
>>> This is an FS-layer change, plus support needed in the DB layers to be
>>> able to replace an existing revision and edit other metadata.
>>> * Approach 2:
>>> Extend Subversion's path-based authz semantics to enable us to block
>>> access to /path/to/foo_at_50.
>> I was just wondering why I saw nails everywhere I looked, until I
>> noticed the hammer in my hand ... :)
>> Seriously: don't try to overload path-based authz [...]
> Thanks... but please read the rest of the thread first :-) I'm not.

Well yes; i did read it. Part of the differenceis the "repos-level" vs.
"filesystem-level", and with obliterate, you're deep in the latter.
Sooner or later.

> But even after reading what I'm thinking about, you may think it's not
> something I should even think about. Why am I thinking like this?
> Because I see a similarity between authz and the data-hiding requirement
> which is a necessary semantic part of "obliterate". I think it is worth
> examining this similarity to learn something from it, even though the
> obvious (and almost vertainly best) implementation is to actually remove
> stuff from the FS rather than introduce a special "hiding" layer.

There are similarities ... I can see two:

    * The concept of hiding something from clients.
    * The pain that happens to clients' existing working copies when you
      hide or unhide something.

There are also differences:

    * Authz is (currently) time-irrelevant; your proposed obliterate
      works on specific revisions.
    * Obliterate doesn't care who's looking at the tree; authz does.
    * Authz is (currenty, brokenly :) a RA-layer-specific optional
      feature; obliterate cannot be.

Last but not least: Data hiding is only one aspect of obliterate. Wait
one moment while I move these sheep's entrails to grab my crystal ball
... ah. It says here that once you start on the space-saving and/or
data-erasing aspect, you'll want the FS-level data hiding anyway as
twiddling txns is unavoidable.

Also, as far as I can remember, our authz isn't really very good at
hiding paths. ISTR issues about that, e.g., that when you have no access
to A/X, you can still see X in A, though not its contents.

So it appears that if you piggy-back "hiding obliterate" onto the authz
layer, you may first have to fix the authz layer, and then later do all
the FS-related work anyway. Low-hanging fruit may on occasion turn out
to be overripe durian, but de gustibus non disputandum est.

-- Brane

Received on 2009-10-01 21:13:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.