Issue #2389 is about taking the conditional language out of
repos/README.txt files. Right now it says that db/ might be a
Berkeley DB environment. As the issue points out, that's a silly
thing to say -- we ought to be able to *know*, at repos creation time,
whether it's FSFS or BDB, and write out the appropriate README.txt.
However, this turns out to be trickier than one would think, due to
library boundary concerns. See the issue for details.
Anyway, some of the solutions involve creating a public svn_fs_type()
API, a step that I had deep reservations about. In response, MaxB
wrote this in the issue:
> We need a svn_fs_type() query function for other reasons, too - to
> have libsvn_repos not lock the locks/db.lock file when working with
> FSFS repositories, in order to get them working on Win9x.
>
> [...]
My concern is: is svn_fs_type() really the right solution to the
locks/db.lock file problem?
If libsvn_repos() needs to change its behavior based on a fact about
the FS layer, then there should be a query function to discover that
particular fact, rather than a query function to answer the generic
question "What FS backend is this?". If we were to do it the latter
way, then libsvn_repos would have to encode knowledge that is really
in the purview of libsvn_fs -- i.e., libsvn_repos would somehow "know"
that for bdb, you do lock locks/db.lock, and for fsfs you don't. But
instead, it should, for example, ask the question "Do I need to lock
db.lock?" and get back a yes/no answer.
I think it's a Very Good Thing that thus far, we have no API for
discovering what type of filesystem a repository is using. This keeps
us honest. If libsvn_repos needs to do things differently based on
the fs backend, then we should be asking ourselves what's really going
on. I understand that for some cases (apparently Win9x is one of
them), libsvn_repos may indeed need to adjust its behavior, but we can
still try to do it in as non-dirty a way as possible.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 29 18:18:14 2005