attached mail follows:
Hey:
Greg Stein wrote:
> 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.
>
Great!
>
> > 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:
This was my major area of concern.
>
>
> '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)
>
Great approach. Thanks. You have thought about this before I take it?
>
> 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).
OK, I'll make this my goal while getting my brain wrapped around the existing FS
code.
I need to spend some time with the coding standards as well.
>
>
> 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 :-)
I know. But I need something like this to get my enthusiasm back. I've spent too
much time dealing with customers lately. Plus, everything I've written for the last
two years has been on my own. It will be nice to work with other folks again.
>
>
> 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.
Ok, I'll do my best.
>
>
> 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
Thanks for the response,
gat
>
>
> --
> 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:34:51 2002