On Tue, Dec 12, 2000 at 09:13:19AM -0500, Jim Blandy wrote:
>
> > Strictly speaking, our dependency on it would be pretty light.
> > mod_dav_svn can just use APRUTIL via Apache itself. However, the FS and
> > the server tool(s) will need MD5 hashing and DBM support (the latter
> > because mod_dav_svn will use DBM for some stuff, and the tool will need
> > to deal with those).
> > [ if Berkeley DB utils were exported from FS, then I'd probably use that;
> > even better is to add DB3 support to APRUTIL's DBM support. ]
>
> Fitting Berkeley DB into some generic DBM interface sounds pretty
> doable. I'd also be happy to export some generic "utility" functions
> from svn_fs.h, which might allow tighter integration with a given FS
> object.
I just coded a whopper patch into the "apr_dbm" feature of APRUTIL. The
interface now talks to: SDBM, GDBM, DB1, DB_185, DB2, and DB3. Whee!
[ the DB* part is new. still have some configure magic and testing, but the
code is fully written and compiles against everything ]
Background: mod_dav_svn has to store mappings of DAV Activity names to FS
Transaction names. This will be a little bitty table manipulated thru
apr_dbm (rather than coding against a specific DBM interface).
The server admin tool would also use apr_dbm to read mod_dav_svn's tables.
We do have a slight gotcha in case Apache is built with an APRUTIL that uses
a different backend DBM than our server admin tool. I believe we'll be okay,
though, as long as both Apache and SVN allow configure to just default both
of them. We can also have SVN's configure examine the Apache installation to
see what it used and use the same setting for SVN's copy of APRUTIL.
[ and one day, we'll have aprutil as a shared lib and it won't matter ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:19 2006