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