You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2004/04/26 10:25:27 UTC
Re: svn commit: r9487 - in branches/fs-abstraction/subversion: libsvn_fs libsvn_fs_baseline
On Apr 25, 2004, at 11:46 PM, ghudson@tigris.org wrote:
> Author: ghudson
> Date: Sat Apr 24 19:57:49 2004
> New Revision: 9487
>
> Added:
> branches/fs-abstraction/subversion/libsvn_fs_baseline/
> - copied from r9486,
> branches/fs-abstraction/subversion/libsvn_fs/
> Removed:
> branches/fs-abstraction/subversion/libsvn_fs/
> Log:
> On fs-abstraction branch, rename libsvn_fs to libsvn_fs_baseline.
>
> * libsvn_fs: Remove (to be replaced with loader library).
> * libsvn_fs_baseline: Add, renamed from libsvn_fs.
Any reason you're calling it 'libsvn_fs_baseline' instead of
'libsvn_fs_bdb' or something else that indicates it uses berkeley db?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in branches/fs-abstraction/subversion: libsvn_fs
libsvn_fs_baseline
Posted by Daniel Rall <dl...@collab.net>.
Greg Hudson wrote:
> On Mon, 2004-04-26 at 16:02, Garrett Rooney wrote:
...
>>I'd also say that 'libsvn_fs_base' would be nicer than
>>'libsvn_fs_baseline', to stress that it's a sort of 'base class' for
>>other db based implementations to extend. I'm not sure what exactly
>>'baseline' indicated to me when I first saw it, but it wasn't that.
>
> I was just following gat's document. I can rename it to "base" if no
> one disagrees. If nothing else, it will eliminate the need to use "bl"
> as an abbreviation, which always seemed terribly opaque to me.
I would prefer "base" to "baseline". I agree that the "bl" abbreviation isn't
entirely obvious.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in branches/fs-abstraction/subversion: libsvn_fs
libsvn_fs_baseline
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Ben Collins-Sussman wrote:
>On Mon, 2004-04-26 at 15:12, Greg Hudson wrote:
>
>
>
>>I was just following gat's document. I can rename it to "base" if no
>>one disagrees. If nothing else, it will eliminate the need to use "bl"
>>as an abbreviation, which always seemed terribly opaque to me.
>>
>>
>
>+1. Please do.
>
>
Sounds good to me.
gat
Re: svn commit: r9487 - in
branches/fs-abstraction/subversion: libsvn_fs libsvn_fs_baseline
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-04-26 at 15:12, Greg Hudson wrote:
> I was just following gat's document. I can rename it to "base" if no
> one disagrees. If nothing else, it will eliminate the need to use "bl"
> as an abbreviation, which always seemed terribly opaque to me.
+1. Please do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in
branches/fs-abstraction/subversion: libsvn_fs libsvn_fs_baseline
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-04-26 at 16:02, Garrett Rooney wrote:
> Well, I don't know if I particularly like building infrastructure for
> theoretical new backends for the fs library, but hey, I'm not the one
> doing the work.
Since there's already some care taken in libsvn_fs to separate out most
of the BDB-specific parts, I think it would create a mess to start using
"svn_fs_bdb" as a library prefix for symbols there.
(Also, the only FSP infrastructure being built here is in the new name
choice for the existing FS implementation.)
> I'd also say that 'libsvn_fs_base' would be nicer than
> 'libsvn_fs_baseline', to stress that it's a sort of 'base class' for
> other db based implementations to extend. I'm not sure what exactly
> 'baseline' indicated to me when I first saw it, but it wasn't that.
I was just following gat's document. I can rename it to "base" if no
one disagrees. If nothing else, it will eliminate the need to use "bl"
as an abbreviation, which always seemed terribly opaque to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in branches/fs-abstraction/subversion: libsvn_fs
libsvn_fs_baseline
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Greg Hudson wrote:
> On Mon, 2004-04-26 at 10:45, Glenn A. Thompson wrote:
>
>>>Any reason you're calling it 'libsvn_fs_baseline' instead of
>>>'libsvn_fs_bdb' or something else that indicates it uses berkeley db?
>>
>>Because, there will be other DB backends using the same abstraction.
>>The "inner vtable", will allow other DB backends to be used within the
>>current FS implementation.
>>I don't believe Greg is working on that part. He's focussing on the
>>outer abstraction. Right Greg?
>
>
> Correct.
Well, I don't know if I particularly like building infrastructure for
theoretical new backends for the fs library, but hey, I'm not the one
doing the work.
I'd also say that 'libsvn_fs_base' would be nicer than
'libsvn_fs_baseline', to stress that it's a sort of 'base class' for
other db based implementations to extend. I'm not sure what exactly
'baseline' indicated to me when I first saw it, but it wasn't that.
> My initial plan was that you'd set "fsap-name" in the fs_config passed
> to svn_fs_new if you wanted svn_fs_create() to use anything other the
> baseline FSAP, and then (in the future) you'd set "fsp-name" if you
> wanted the baseline FSAP to use anything other than the BDB FSP. I
> recently changed the first part so that you just pass an fsap_name
> parameter to the new svn_fs_create() function, but the baseline FSAP
> will still probably have to use the fs_config parameter to choose
> between FSPs, since there's no other way to get a parameter down to that
> level.
makes sense.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in branches/fs-abstraction/subversion:
libsvn_fs libsvn_fs_baseline
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-04-26 at 10:45, Glenn A. Thompson wrote:
> > Any reason you're calling it 'libsvn_fs_baseline' instead of
> > 'libsvn_fs_bdb' or something else that indicates it uses berkeley db?
>
> Because, there will be other DB backends using the same abstraction.
> The "inner vtable", will allow other DB backends to be used within the
> current FS implementation.
> I don't believe Greg is working on that part. He's focussing on the
> outer abstraction. Right Greg?
Correct.
My initial plan was that you'd set "fsap-name" in the fs_config passed
to svn_fs_new if you wanted svn_fs_create() to use anything other the
baseline FSAP, and then (in the future) you'd set "fsp-name" if you
wanted the baseline FSAP to use anything other than the BDB FSP. I
recently changed the first part so that you just pass an fsap_name
parameter to the new svn_fs_create() function, but the baseline FSAP
will still probably have to use the fs_config parameter to choose
between FSPs, since there's no other way to get a parameter down to that
level.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9487 - in branches/fs-abstraction/subversion: libsvn_fs
libsvn_fs_baseline
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>> Log:
>> On fs-abstraction branch, rename libsvn_fs to libsvn_fs_baseline.
>>
>> * libsvn_fs: Remove (to be replaced with loader library).
>> * libsvn_fs_baseline: Add, renamed from libsvn_fs.
>
>
> Any reason you're calling it 'libsvn_fs_baseline' instead of
> 'libsvn_fs_bdb' or something else that indicates it uses berkeley db?
Because, there will be other DB backends using the same abstraction.
The "inner vtable", will allow other DB backends to be used within the
current FS implementation.
I don't believe Greg is working on that part. He's focussing on the
outer abstraction. Right Greg?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org