Two approaches to data-hiding (for obliterate)

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.

These both sound feasible to me. Approach 1 gets us much closer to being
able to recover the disk space. This is the approach I'm looking at so
far. Approach 2 sounds like it might be quicker (easier) to reach the
data-hiding stage. Indeed, it is already a usable solution for hiding an
unwanted file if the file's path will never need to be visible in any
revision. But Greg cautions me that it will be hard.

Can anyone comment?

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402554
Received on 2009-10-01 16:49:00 CEST