These last few days I've been working down through the layers, looking
at a call graph something like this:
"svn obliterate URL_at_REV"
Most of these calls will do little but forward the request on down the
chain. Somewhare in the upper layers will be the logic that decides
which node-revs to obliterate, based on what the client wants, and
decides how many calls to make to the lower layers based on how
"powerful" the lower APIs are.
At the moment I'm not thinking about the high-level logic, but instead
looking at how the repos layer downwards will modify one revision.
# repos layer
// For now, let's just suppose that the API is only to be capable of
removing one path from one rev.
# FS layer
// Special versions of the normal-txn "begin" and "commit" APIs.
// I've yet to discover whether the standard APIs for modifying
// the contents of a transaction are sufficient to use between
// these "begin" and "commit" calls.
// Like svn_fs_fs__begin_txn() but with no special rev-props (no need
to change the "date" property, for example).
// Where the bulk of the new work will be.
All of these APIs take a revision number as a parameter, and replace the
specified revision with a modified version of itself.
Received on 2009-10-05 19:10:45 CEST