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

Re: obliterate in trunk (was: svn commit: r39745 - trunk/subversion/svn)

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 12 Oct 2009 16:45:51 -0700

On Mon, Oct 12, 2009 at 4:28 PM, Branko ─îibej <brane_at_xbc.nu> wrote:
> David Glasser wrote:
>> For what it's worth, the current schema for the rep-sharing DB is
>> completely incompatible with "remove data from server" obliterate
> You mean in the sense that you can't reasonably in real-time remove
> entries from the datbase, right? I can imagine having separate, offline
> process that would scan the whole repository for a particular
> representation hash and do the actual on-disk data removal and rep-cache
> cleanup. But it would require a write lock on the repository.

OK, sure, if you're OK with "disable commits while we walk the entire
repository, every single node" then it would work (though note that a
few days ago we decided that the rep-sharing DB should be written
after the write lock is dropped, which could hypothetically be minorly
problematic here). Of course, that's going to be kind of slow. But I
guess we do even have some repo-walking logic in there already (in the
svnadmin verify code, IIRC).


glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
Received on 2009-10-13 23:31:16 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.