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

Two approaches to data-hiding (for obliterate)

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 1 Oct 2009 15:48:29 +0100

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

Received on 2009-10-01 16:49:00 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.