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

Re: Two approaches to data-hiding (for obliterate)

From: Branko Cibej <brane_at_xbc.nu>
Date: Thu, 01 Oct 2009 19:16:21 +0200

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

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