Blair Zajac wrote:
> Why is svn_repos_deleted_rev is in svn_repos.h and not in svn_fs.h?
> This is new in 1.5, so we could move it still.
> It's the natural place I would look for that method, instead of
> In fact, there's lots of interesting methods there that look like they
> belong in svn_fs.h, not that we would move them now? They take
> svn_fs_t, not svn_repos_t.
> What's the distinction between a method appearing in svn_fs.h and
Methods appear in svn_fs.h when their implementations live in libsvn_fs,
libsvn_fs_fs_, and libsvn_fs_base. These libraries deal strictly with the
versioned filesystem implementation. No hooks, no authz logic -- nothing
that the repository layer adds on.
Methods appear in svn_repos.h when their implementations live in libsvn_repos.
So, the general rule here is, drop your function in the deepest layer that
FWIW, I agree that svn_repos_deleted_rev should be svn_fs_deleted_rev().
I suspect that people creating these new functions are simply trying to keep
"history reporting" functions lumped together in libsvn_repos without much
thought as to proper layering.
By the way, I see a really useful helper function just below
svn_repos_deleted_rev(): check_ancestry_of_peg_path() could really stand to
go public as svn_fs_check_ancestry() and get more generic by taking (path1,
rev1, path2, rev2) instead of (path, pegrev, future_rev).
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Aug 1 15:51:33 2007