Re: svn_fs_open_berkeley

Yoshiki Hayashi <yoshiki@xemacs.org> writes:

> In commit #661, svn_fs_open_berkeley interface is changed to take
> path to Berkely DB database (previously called env_path) instead of
> top level Subversion directory.

Yep. That's correct.

> Because of this change, the client of svn_fs.h need to be aware that
> Berkeley DB is stored in SVN_REPOS_PATH/db.

That's correct. A client of *just* svn_fs.h (not svn_repos.h) will
need to know that fact. Such a client, by strictly using the svn_fs.h
API, is claiming to be a client of the filesystem, not of a Subversion
repository, else he'd be using the svn_repos.h API.

> This doesn't look too good. Is only canonical way to get svn_fs_t
> object is to use svn_repos_open and then call svn_repos_fs?

No. There are two ways to get an svn_fs_t * object.

1. Use svn_fs_new() (and initialize it with svn_fs_open_berkeley).
    In this case, you are operating not on a Subversion repository,
    but on only the FS subsystem of a Subversion repository.

2. Use svn_repos_open() followed by svn_repos_fs(). In this case,
    you are operating on a Subversion repository, specifically
    interested in the FS subsystem portion of it.

The fs-tests prove that the FS library needs no Subversion repository
in order to function (just run fs-tests and look at the test-repo-*
subdirectories that get created -- they are *just* the BerkeleyDB
environments!).

The repos-test binary (and svn, svnadmin, svnlook, etc.) are,
however, using the svn_repos.h interface (since they are users of
Subversion repositories), and running all the other tests in our test
suite will demonstrate that they too work just fine. Again, run
repos-test and look at the test-repo-* directories *it* creates --
those are full-fledged Subversion repositories.

The idea here is that FS API is meants to be modular, and theoretically
Subversion-independent. The REPOS API *is* Subversion.

Questions/comments are (as always) welcome.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006