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.
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.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402626
Received on 2009-10-01 19:29:58 CEST