[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question about issue #2389 (fixing repos/README.txt).

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-09-03 18:57:34 CEST

kfogel@collab.net wrote:
> "Max Bowsher" <maxb@ukf.net> writes:
>> 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.
>
> Okay, I'll buy that argument.
>
> Max, would you like me to implement this, or are you on it?

I'm happy to get on it once I get overrunning #525 work done (which is
actually nearly finished, now).

I'm also happy if you want to handle it.

Related patch: http://svn.haxx.se/dev/archive-2005-08/0702.shtml

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 3 18:59:56 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.