Re: Moving svn_repos_deleted_rev to svn_fs_deleted_rev?

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
> svn_repos.h.
>
> 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
> svn_repos.h?

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
makes sense.

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 <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand