> 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.
As a site maintainer for a multiplatform environment, I think this is
a terrible idea. It would be way too easy for me to naively build
Solaris and IRIX binaries which use ndbm, NetBSD binaries which use
db1, and Linux binaries which use db3. Now people's working
directories (in their shared-filesystem homedirs) simply don't work
between platforms.
For a server, this sort of thing might be reasonable (although there
is a serious upgrade issue if anyone ever wants to add or remove a
database backend or change the default preference order). So I won't
go so far as to say that this aprutil feature should be expunged from
the face of the planet. But we certainly shouldn't use it in the wc.
I remain unconvinced that we need a db for the working copy anyway. I
have sincere doubts that people will ever find a need for more than a
few properties with relatively short values. (And if we ever do get
to that point, there are alternatives, such as making a directory for
properties and putting each property in a different file.)
Received on Sat Oct 21 14:36:22 2006