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

[kf...@collab.net]

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

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

[kf...@collab.net]

kfogel@collab.net writes:
> > I'm also happy if you want to handle it.
> > 
> > Related patch: http://svn.haxx.se/dev/archive-2005-08/0702.shtml
> 
> If can do something to lighten your load so you can concentrate on
> #525, I am happy to do it.  I'll take care of svn_fs_type().

Done in r16162.

-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

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

[kf...@collab.net]

"Max Bowsher" <ma...@ukf.net> writes:
> kfogel@collab.net wrote:
> > "Max Bowsher" <ma...@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).

/me sends up a cheer

> I'm also happy if you want to handle it.
> 
> Related patch: http://svn.haxx.se/dev/archive-2005-08/0702.shtml

If can do something to lighten your load so you can concentrate on
#525, I am happy to do it.  I'll take care of svn_fs_type().

-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

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

[Max Bowsher <ma...@ukf.net>]

kfogel@collab.net wrote:
> "Max Bowsher" <ma...@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

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

[kf...@collab.net]

"Max Bowsher" <ma...@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?

-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

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

[Max Bowsher <ma...@ukf.net>]

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