Hey,
>Yeah, yeah, we knew that. The state is intermediate, but I'm sure
>Glenn wouldn't mind using the svn_fs__ prefix in the meantime.
>
>
>
>>>* subversion/libsvn_fs/bdb/bdb-fs.h
>>> New. This file contains table "open function" declarations removed
>>> from their respective xxx-table.h include files. It also has
>>>
>>>
>>Why just the open functions? That seems like a strange division. The other
>>functions in the API are quite specific to the BDB implementation, so why
>>didn't they move, too? Why not just put all of the prototypes into bdb-fs.h?
>>
>>
>
>Hmm, yeah, I have to admit that I'm sure why the division happened
>here, either.
>
>
Yeah I don't care. But I do think backing out the xxx-table.c and
xxx-table.h is the right thing to do both long and short term. I'll try
it after I suck down some coffee. Yes, I'm a coffee addict.
>
>
>>Call me -0.5 on this commit :-(
>>
>>
>
>I can certainly revert the commit. Here's what I'd rather do though:
>
> 1. Branch from trunk@HEAD right now (/branches/fs-db-abstract)
>
> 2. Revert 5212 from trunk
>
> 3. Give Glenn commit privs to the new branch with the stipulation
> that his work *will not* get merged into the trunk unless he
> continues to work incrementally, poking us (me?) at his
> breakpoints where merging with trunk would be appropriate.
>
>I *want* this DB abstraction to happen. It is a Good Thing for
>Subversion (and for CollabNet, IMO).
>
>
Fine with we. But I think this -0.5 is an over-reaction to a whoops.
>
>
>>It would seem to be better to define the vtable, complete the discussion
>>around *that*, add it to the code, and then start migrating stuff
>>into it.
>>
>>
>
>That is a good step, but this change (at least, most of it) was a
>necessary precursor to such a move. This change was long overdue, and
>was simply the completion of his previous one (where much of the
>BDB-table stuff moved into the /bdb subdir).
>
>
Like I said, I did this.
>
>
>>With the current approach, a lot of stuff is shifting around, but the
>>reasoning isn't clear at all. And what that *really* means is that we have
>>no way to evaluate the *design* of this vtable stuff.
>>
>>
>
>Glenn's design has been publically available on his website for
>... gosh, many many months (has it been a year yet?), and he's been
>very good at advertising that location in his correspondences to this
>list. If you want to evaluate the design for yourself, go read it.
>
>
>
>>I'm highly suspect of the design right now. The FS is very dependent upon
>>the BDB-based design.
>>
>>
>
>The only aspect of our file system that is strongly tied to Berkeley
>(that I can think of right now) is the trail notion. All of the
>tree/dag stuff has long since been converted to use internal
>structures to represent the data being passed around (i.e., nobody
>except the actual BDB-calling functions knows anything about skels) --
>a new database backend need only know how to populate and store
>representations of those structures, and to answer the generic
>questions we ask of the database layer.
>
>
Well in my master patch trails aren't. They are abstracted. The vtable
components that provide for this are currently part of the API vtable.
I want to handle this differently long term. A FS implementer should
have the choice as to whether they use them or not. If there is no API
level then vtable this is a mute point.
>
>
>>While I'm fine with a vtable for the database portions (the
>>"backend"), I'm really not a fan of a vtable for the FS API
>>itself. I don't really see a need to change things at that level;
>>the probability for changing the semantics is just too great,
>>leading to problems down the line. Just how much rope do we want to
>>provide?
>>
>>
>
>For what it's worth, I also would prefer static FS APIs, and don't see
>the need for an FS vtable. Glenn, how much of your design is
>absolutely dependent on that part of the change. If memory serves, it
>was more about flexibility for implementers of new schemas than for
>correctness. How wrong am I?
>
>
Yes you are mostly correct. But at least *some* of the API functions
have to be in a vtable. Open, create, recover, etc.
I see trails as being something that needs to be kept separate from the
"baseline" implementation as well as separate from the backend vtable.
It's in the API vtable now.
There still remains the possibility that under certain circumstances, a
given txn body will have to be implemented in a way which is
incompatible with the BDB solution. Without a vtable I'd be forced to
deal with these situations one by one. It's rather stifling from my
perspective. I'd like to see FS developers be able to come to the list
with a mostly working version of their wares much the same way Greg
Hudson came to the list with ra_svn. And aren't we *all* glad he did.
Sometimes code evolves from a gut feeling. One has to mold it a while
before it can be released for public scrutiny. I think was Greg Hudson
said that sometimes you don't know if something will work until you are
almost done with it. I want to encourage people to try.
For good reason, I feel like the FS code is treated with a "be careful
in there" attitude. I want to open it up so that people can develop new
ideas without worrying they are going to "F" up existing repos. Lets
get the vtable in early and let people go for it without being concerned
they are screwing up someone else. After all, SQL is just the tip of
the iceberg for me.
Now where is that pot-o-coffee?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 6 20:26:16 2003