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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402654
Received on 2009-10-01 21:13:37 CEST