On Wed, Apr 24, 2002 at 03:49:33PM -0400, Glenn A. Thompson wrote:
>...
> If anyone has any feelings about where I am headed; I welcome them. I won't
> be able to dig back in for another week or so.
> Sometime after that I will post a document with more meat. Is this an
> acceptable way to jump in?
Totally fine.
> I want to reuse as much of the existing FS code as possible. I'm concerned
> that this my require some refactoring of code. I want to minimize any impact
> on the existing baseline while also minimizing potental implementation
> specific behavior/features/bugs. It seems to me that this goal my be a bit of
> a tightrope walk.
Refactoring is going to be the major work. Here is a basic way to approach
the problem:
'skel_t' is your focus. Anywhere we use a skel_t, implies marshalling of
data into a format storable into the BerkeleyDB. The skel_t stuff needs to
be BDB specific. Thus, libsvn_fs needs individual C structures for each
kind of data represented in a skel_t. For example, a structure for
representing a revision node. These structures would be some combination
of standard C datatypes, APR hash tables, APR arrays, whatever. These data
structures then become the standard basis of operation, and the
marshalling to/from skel_t's flat format are relegated to the BDB-specific
backend. A SQL layer will map the structures into a table-oriented form,
and a SQL-database-specific layer under that maps them to Oracle or MySQL.
(it may be that the extra SQL layer doesn't exist, but I imagine there is
some reuse possible there)
So... I believe your first task is to isolate the data structures and define
them. We then begin to introduce them into libsvn_fs, with the appropriate
skel_t marshalling code to/from the structures. (and we leave the skel_t to
string marshalling untouched).
After a while, all the skel_t handling will be isolated, and you can begin
to partition the libsvn_fs code, with a hard API between the FS and the
backend database, focused around these structures as the communication
mechanism across the API.
You've got your work cut out for you :-)
As long as the changes are *VERY* incremental, then I believe we'd be happy
to integrate them into the FS. Thus, during your work, you'll need to
concentrate on keeping each change to a very small, consumable patch. If it
ever gets to be too much, we'll punt, and that would be everything would get
relegated to post 1.0.
In any case, I suspect that it won't be possible for you do complete these
before we decide to hit 1.0. That should be fine, though, as you'll still
have a head start, and it could be finished "soon" after 1.0 goes out.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 22:05:12 2002