[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: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 1 Oct 2009 10:53:37 -0400

On Thu, Oct 1, 2009 at 10:48 AM, Julian Foad <julian.foad_at_wandisco.com> 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 do not think this would be a great way to do it. mod_authz_svn is
an optional module and it is possible to put other authz
implementations in place. Of course it also does not apply to file://
access which means that tools like ViewVC that access the repository
directly would have to be enhanced to apply whatever authz rules we
are doing in mod_authz.

Besides, a very common use case today for obliterate is to simply
block that a path ever existed in the repository (all revisions).
This can be done today using authz but I have never heard anyone
suggest they considered that a decent option. So there is no reason
to think taking this idea further would help.

Mark Phippard
Received on 2009-10-01 16:54:17 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.