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

A panoply of DB's

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-02-17 00:15:43 CET

Greg Stein <gstein@lyra.org> writes:
> I'm assuming that we'll be picking up an APRUTIL dependency by M2. Assuming
> that is the case, then I'd suggest that you use apr_dbm for the client-side
> property storage. That will pick up whatever is on the system for the DBM
> storage, rather than adding a (DB3) dependency to the client.
> Currently, it can work against DB1, DB1.85, DB2, DB3, SDBM, and GDBM. Coming
> "soon" is NDBM. One of those will "always" be on your system.

Hmm. Is that really a good idea?

Working copies won't be portable from one system to another --- their
form will depend on what DB you happened to have installed when you
configured Subversion.

If you build Subversion, make some working directories, install a new
"preferable" DB library on your system, and then rebuild Subversion,
the new Subversion won't be able to read your working directories.
(Unless APRUTIL provides some kind of auto-detection and run-time
selection of the appropriate back end.) And it'll start writing files
in a different format, that the old Subversion executables can't read.

These aren't show-stoppers, I guess, but it's a bit weird.

It is an argument in favor of our existing nice readable text file
formats. (Frankly, I doubt the efficiency will be an issue. The
files just won't be that large, usually.)
Received on Sat Oct 21 14:36:22 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.