[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Using PostgreSQL instead of Berkeley DB??

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-04-24 22:04:58 CEST

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.


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

This is an archived mail posted to the Subversion Dev mailing list.