On Mon, Oct 5, 2009 at 1:10 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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.
Was there a specific use-case or reason that has caused this to be
pushed down to the client layers? I thought we were planning for
obliterate to be an svnadmin function that required physical access to
the repository. If we are planning to allow any client to obliterate
revisions, what sort of access control are we planning? Just
something with hook scripts, similar to how we treat revision property
changes?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403819
Received on 2009-10-05 19:16:52 CEST