kfogel@collab.net wrote:
> 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.
I think that we ought to have a svn_fs_type() API anyway, because it has a
legitimate use: Allowing svnadmin, or similar GUI programs, to inform the
user of the type of a repository without resorting to manually peeking into
it to see. After all, since bdb and fsfs repositories have to be handled by
an administrator in different ways in some cases, there ought to be an
official way to tell them apart.
Now, building on the above premise that a svn_fs_type() is worthwhile in its
own right, I don't think an additional feature test API is worthwhile,
because this isn't a mechanism that needs to be extensible. We should
preserve libsvn_repos's independence from the fs-type in every aspect except
where compatibility forces us to give in. In this case, the issue is that
part of the BDB-specific locking arrangements were engineered into
libsvn_repos, not libsvn_fs. We have learnt from our mistake, and will not
repeat it, so we can state with certainty that locks/db.lock will only ever
be required for the bdb fs-type - fsfs, and *all future fs-types yet to be
invented* will not use locks/db.lock. Come 2.0, the entire issue will go
away entirely, when the compatibility break allows us to force the remaining
BDB-specific locking down into the bdb fs module, where it belongs.
Max.
---------------------------------------------------------------------
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:56:15 2005