--On Wednesday, October 16, 2002 8:26 PM +0200
"=?UTF-8?B?QnJhbmtvIMSMaWJlag==?=" <brane@xbc.nu> wrote:
> 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.
But, that's not how we do it now. Please take a look at
subversion/libsvn_fs/fs.c:62. Those values come explicitly from
autoconf not from the BDB headers. This is why I said I think we
need to have a SVN_FS_GOT_DB_* to parallel SV_FS_WANT_DB_*. We could
toss the SVN_FS_WANT_DB_* entirely and just hope that the includes
are right so we can use the BDB header info. But, ISTR that people
have had problems with the BDB headers misreporting the version
number (rather the compiler getting the wrong includes, but the
linker links against the right library).
> 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.:
I think someone said before that we don't want to use functions to
access BDB. But, we're sort of tilting that way anyway...
Yes, we could create a DB layer here by abstracting all BDB calls.
Then, I'd say that we should just fix up APR-util's dbm API to fully
support SVN and be done with it. The biggest thing it'd need is
transactional support as well as version-query support.
> /* 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;
Part of the problem is that there is no common header file that all
of the BDB-using files include that makes sense to include this. So,
I guess we'd have to add a new file? *sigh*
> Sure we don't. I for one don't believe that you should obfuscate C
> code just because you can
I guess my preference is to keep the code as close to where it is as
used as possible. And, I just don't have the time to go create a new
DB abstraction layer...
> 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.
I don't think it's as trivial as it should have been. This migration
path is sucky. Any change to the API like this should have been in a
major version not a minor version. *sigh*
> 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.
Then, is it always recommended to run 'db_recover -ve' whenever the
BDB version changes? I couldn't find anything along that line in
their readmes.
I guess part of my concern is that if we *can* wedge the repos with
4.0, but not with 4.1, why are we doing anyone a favor by supporting
a known broken BDB version? -- 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 20:50:34 2002