Justin Erenkrantz wrote:
> --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.
Um, no, the _code_ has to remember the version numbers at build time,
and check them again at runtime. That's not something you can do in
autoconf, anyway.
> 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));
I'm fairly sure I could come up with an even uglier hack. But I could
also come up with something much cleaner, e.g.:
/* Just assume we have the DB_VERSION_MAJOR and DB_VERSION_MINOR;
if we don't, we're using the wrong version of BDB anyway. */
#if (DB_VERSION_MAJOR == 4) && (DB_VERSION_MINOR >= 1)
#define SVN_HAS_DB_41 1
#else
#define SVN_HAS_DB_41 0
#endif
extern const int svn_bdb_version_major;
extern const int svn_bdb_version_minor;
...
const int svn_bdb_version_major = DB_VERSION_MAJOR;
const int svn_bdb_version_minor = DB_VERSION_MINOR;
svn_error_t *svn_bdb_open(DB *db, const char *file, DBTYPE type,
u_int32_t flags, int mode)
{
int major, minor;
db_version(&major, &minor, NULL):
if (major != svn_bdb_version_major || minor != svn_bdb_version_minor)
return svn_error_create(/* something appropriate */);
#if SVN_HAS_DB_41
DB_ERR (db->open(db, NULL, file, 0, type, flags | DB_AUTO_COMMIT, mode));
#else
DB_ERR (return db->open(db, file, 0, type, flags, mode));
#endif
return SVN_NO_ERROR;
}
> If you like that strategy and think it promotes clean code, well, we
> don't see alike.
Sure we don't. I for one don't believe that you should obfuscate C code
just because you can
> 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...
That's as may be, but I don't think that's a good enough reason to force
people to install yet another nonstandard package, given how trivial it
is to be compatible with both versions.
> 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.
I'd be very surprised ifi it were a bug. Berkeley's structures are sure
to have changed, and the environment files are just shared mem regions.
> 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
That's very encouraging!
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 16 20:26:49 2002