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

Re: Obliterate - design status - table row changes

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 25 Nov 2009 13:59:50 +0000

Julian Foad wrote:
> My recent focus on Obliterate has been learning how the DB tables hang
> together, working out how I need to change the stored data at the level
> of DB tables, and drawing diagrams of that.
> Links to the diagrams are at the end of
> <http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/design-repos.html>
> and, of those, the pair I've just drawn and committed are "before",
> <http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/schema-bdb-dd1-before.svg> and "after", <http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/schema-bdb-dd1-after.svg>.
> Those show what table rows I think need to change to do a simple
> obliteration of a file "foo", like the first one shown in
> <http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/fspec-dd1/dd1-file-ops.svg>.

I need to break the changes down into two steps. To
obliterate /d/foo_at_50:

  1. adjust any future (younger) revisions to not refer to /d/foo_at_50:
      - any copy-from info
      - any deltas against /d/foo_at_50 representations

  2. change the content of r50.

Logically, these phases could be separated completely. There is no need
to have them in an single atomic transaction, if step 2 checks whether
any further references have been committed since step 1 was performed,
and if the caller can cope with the potential failure of this check by

I think it is right to separate those as much as possible, to keep the
low-level operations as small as possible. The only cases I can think of
in which such a method would be inefficient are:

  * If a rapid and continuing stream of commits is being made, each of
which copies stuff from r50 or makes a file content delta against r50;
but that is a pathological case and I can't imagine a realistic

  * If the check in step 2 is inefficient; but I believe we can find an
efficient way to do it, as hinted at in the section "Construction and
Finalization Checks" in

- Julian

> "Tables"? I'm using "tables" terminology because I'm looking at BDB at
> the moment because it seems better documented. I do intend to implement
> on FSFS first, though, if I can translate what I learned. However, if it
> is difficult to translate this from BDB to FSFS I will probably
> implement first on BDB to get something going, as I think it's important
> to have some working repositories to play with. (I thought I'd have that
> by now but it's not as simple as ... OK, I never believed it would be
> simple, but still.)


Please start new threads on the <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.
Received on 2009-11-25 15:00:22 CET

This is an archived mail posted to the Subversion Dev mailing list.