Re: Obliterate - design status - table row changes

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@50:

  1. adjust any future (younger) revisions to not refer to /d/foo@50:
      - any copy-from info
      - any deltas against /d/foo@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
re-trying.

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
scenario.

  * 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
<http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/design-repos.html>.

- 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.)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2424254

Please start new threads on the <[email protected]> mailing list.
To subscribe to the new list, send an empty e-mail to <[email protected]>.