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"
calls
svn_cl__obliterate()
calls
svn_client_obliterate()
calls
svn_ra_obliterate()
calls
svn_ra__vtable_t:obliterate_path_rev()
calls
svn_ra_local__obliterate_path_rev()
calls
svn_repos_obliterate_path_rev()
calls
svn_fs_begin_obliteration_txn()
svn_fs_commit_obliteration_txn()
calls
svn_fs_t::begin_obliteration_txn()
svn_fs_txn_t::commit_obliteration_txn()
calls
svn_fs_fs__begin_obliteration_txn()
svn_fs_fs__commit_obliteration_txn()
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
svn_repos_obliterate_path_rev(path-in-repos, rev)
// For now, let's just suppose that the API is only to be capable of
removing one path from one rev.
# FS layer
svn_fs_begin_obliteration_txn(rev)
svn_fs_commit_obliteration_txn(rev)
// 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.
svn_fs_t::begin_obliteration_txn(rev)
svn_fs_txn_t::commit_obliteration_txn(rev)
# FSFS
svn_fs_fs__begin_obliteration_txn(rev)
// Like svn_fs_fs__begin_txn() but with no special rev-props (no need
to change the "date" property, for example).
svn_fs_fs__commit_obliteration_txn(rev)
// 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.
Thoughts?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403816
Received on 2009-10-05 19:10:45 CEST