--On Wednesday, October 16, 2002 12:52 PM +0200 brane@xbc.nu wrote:
> We already have autocode that extracts the BDB version number;
> we're checking for 4.0.14 right now, but there's no reason we
> couldn't check for 4.1.x, too. And any part of the code that uses
> BDB will pull in the BDB headers, so that you could ifdef on
> DB_MAJOR and DB_MINOR where necessary. I don't think we need any
> new or different autoconfigury at all.
Nope, all it does is guarantee we have a minimum version - we don't
have macros to determine what version we have. We have to also tweak
the run-time checks to ensure that we run against the version that we
*built* against not the minimum version we requested. So, I believe
that means that the autoconf checks have to extract what we have at
configure-time.
To give you an idea what *every* open call is going to look like,
here's the code to open the changes table and to maintain backwards
compatibility if you rely on the header files:
DB_ERR (changes->open (changes,
#if defined(DB_VERSION_MAJOR) && (DB_VERSION_MAJOR == 4) && \
defined(DB_VERSION_MINOR) && (DB_VERSION_MINOR >= 1)
NULL,
#endif
"changes", 0, DB_BTREE,
(create ? (DB_CREATE | DB_EXCL) : 0)
#if defined(DB_VERSION_MAJOR) && (DB_VERSION_MAJOR == 4) && \
defined(DB_VERSION_MINOR) && (DB_VERSION_MINOR >= 1)
| DB_AUTO_COMMIT
#endif
, 0666));
If you like that strategy and think it promotes clean code, well, we
don't see alike. I think that's ugly and outweighs the few
distributions that ship BDB 4.0. They'll be adding BDB 4.1 soon
enough due to the reliability enhancements...
As an aside, I had to run db_recover -ve (aka 'svnadmin recover') on
all my databases when upgrading to 4.1 - it seems that the databases
are forward-compatible, but not the environments. I wonder if that's
a bug in BDB 4.1. If so, perhaps we should drop a line to Keith and
see if they can resolve that.
But, now, I can't manage to wedge the repository with BDB 4.1. Does
anybody have a sure-fire repro case for wedging repositories? (I've
tried Ctrl+C, kill -9, etc.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 16 19:01:28 2002