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 that is not even part
of the FS proper (and therefore doesn't work for local access, amongst
other things) for solving a prolem that isn't really related to
authorization. It's liable to turn into a can of worms.
Dealing with FS issues and switching txns possibly more complex up
front, but is certainly the right approach to obliterate. IIRC doing the
revision replacement dance shouldn't be too hard, since a revision is
basically just a numbered pointer to a transaction.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402616
Received on 2009-10-01 19:16:33 CEST