Hey:
Bill Tutt wrote:
> Hey, you can get an ER-like diagram for the proposed SVN schema after
> the dump/restore changes get done at:
> http://www.lyra.org/rassilon/SVNModel/SVNProjectv2.pdf
>
Will do
>
> I say ER-like because, it wouldn't be the real physical schema you'd
> want for a SQL store for various reasons. Also check out the
> libsvn_fs/structure document that explains the various concepts.
>
Yeah I think I read that document about a month ago. I will definately read
it several times to pound in the concepts.
I can be a little slow on the uptake sometimes, buuuttttt once I get it, I
get it.
Thanks,
gat
>
> Bill
> ----
> Do you want a dangerous fugitive staying in your flat?
> No.
> Well, don't upset him and he'll be a nice fugitive staying in your flat.
>
>
> > -----Original Message-----
> > From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> > Sent: Wednesday, April 24, 2002 1:36 PM
> > To: Greg Stein
> > Subject: Re: Using PostgreSQL instead of Berkeley DB??
> >
> > 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 Thu Apr 25 02:39:15 2002