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