A panoply of DB's

[Jim Blandy <ji...@zwingli.cygnus.com>]

Greg Stein <gs...@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.)