You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mo DeJong <md...@cygnus.com> on 2001/03/05 08:48:58 UTC
Patch to build db in the tree.
Hi all.
So it seems that most folks are
going to need to build an updated
version of Berkeley DB for use
with subversion. I have a Red Hat
6.2 box and it appears that my
version of Berkeley DB is too
old for subversion :(
Since we need to build it,
I decided to add db to the
subversion top-level configure
by duplicating how neon is
integrated.
Why build our own Berkeley DB?
(1) Every developer should be
running the exact same code.
There has already been one example
where different versions of the
db lib have caused problems.
Statically linking in a known
version of Berkeley DB is the
best way to make sure nobody
get bitten by some odd little
bug caused by version conflicts.
(2) Building subversion should
be easy.
It is really critical that
folks are able to build with
a minimum of fuss. Folks
don't want to go download
and build a bunch of stuff.
One toplevel configure
should do it all for them.
We should concern ourselves
with making it easy for joe
developer out there to get
subversion built with the
minimum of fuss.
Distribution builders
and power users can always
use an existing library via
the --with-berkeley-db switch.
(3) The client side fs should build
by default.
The default build should support
a local filesystem as well as
a networked interface. Currently,
the local fs code will not get
built if a good version of db
can not be found on the system.
Unknowns:
Is db-3.2.9 the right version?
Should the default db configure
be static? We would need to
pass the --enable-dynamic
option to db's configure
script to enable shared libs.
Shared libs are a bit more
dangerous since they are
harder to build/debug and
more can go wrong. On the
other hand svn libs are
currently being built shared.
Should the --enable-debug or
--enable-posixmutexes flags
be passed to db's configure?
Should the db dir be required?
This patch will build the
old way if the db subdir
is not in the tree or if
another location is passed
via the --with-berkeley-db
switch.
cheers
Mo DeJong
Red Hat Inc
2001-03-04 Mo DeJong <md...@redhat.com>
* Makefile.am: Add DB_DUBDIR to SUBDIRS.
DB_SUBDIR is empty when db is not built
in the subversion tree.
* autogen.sh: Add gen time check for
db subdir.
* configure.in: Configure in the db
subdir if it exists.
* ac-helpers/berkeley-db.m4: Add
new builtin status. It will set the
flags to use the db dir in the
build directory.
* ac-helpers/get-db-ver.sh: Add
script to determine the version
of the db package in the srcdir.
(New File)
% cat ac-helpers/get-db-ver.sh
#! /bin/sh
#
# USAGE: get-db-ver.sh DIRECTORY
#
conf=$1/dist/RELEASE
# Tested with the 3.2.9 release from Sleepycat
major=`sed -n '/DB_VERSION_MAJOR=/s/.*=//p' $conf`
minor=`sed -n '/DB_VERSION_MINOR=/s/.*=//p' $conf`
release=`sed -n '/DB_VERSION_PATCH=/s/.*=//p' $conf`
echo $major.$minor.$release
(Patch files)
Index: Makefile.am
===================================================================
RCS file: /cvs/subversion/Makefile.am,v
retrieving revision 1.17
diff -u -r1.17 Makefile.am
--- Makefile.am 2001/02/05 19:21:25 1.17
+++ Makefile.am 2001/03/05 08:10:56
@@ -8,7 +8,7 @@
## dependencies between Makefile.am, Makefile.in, and Makefile.
## In other words, SUBDIRS does not completely control automake
## generation.
-SUBDIRS = apr expat-lite neon subversion doc
+SUBDIRS = apr expat-lite neon @DB_SUBDIR@ subversion doc
ACLOCAL = @ACLOCAL@ -I ac-helpers
Index: autogen.sh
===================================================================
RCS file: /cvs/subversion/autogen.sh,v
retrieving revision 1.36
diff -u -r1.36 autogen.sh
--- autogen.sh 2001/02/24 09:09:32 1.36
+++ autogen.sh 2001/03/05 08:10:56
@@ -33,12 +33,14 @@
# Handle the neon/ subdir
NEON_WANTED=0.11.0
+NEON_URL="http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
+
if [ ! -d neon ]; then
echo ""
echo "...Uh oh, there is a problem."
echo "You don't have a neon/ subdirectory here."
echo "Please get neon ${NEON_WANTED} from:"
- echo " http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
+ echo " ${NEON_URL}"
echo ""
echo "Unpack the archive using tar/gunzip and rename the resulting"
echo "directory from ./neon-${NEON_WANTED}/ to ./neon/"
@@ -52,13 +54,50 @@
echo "You have a neon/ subdir containing version $NEON_VERSION,"
echo "but Subversion needs neon ${NEON_WANTED}."
echo "Please get neon ${NEON_WANTED} from:"
- echo " http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
+ echo " ${NEON_URL}"
echo ""
echo "Unpack the archive using tar/gunzip and rename the resulting"
echo "directory from ./neon-${NEON_WANTED}/ to ./neon/"
echo ""
exit 1
fi
+
+
+# Handle the db/ subdir
+DB_WANTED=3.2.9
+DB_URL="http://www.sleepycat.com/update/3.2.9/db-3.2.9.tar.gz"
+
+if [ ! -d db ]; then
+ echo ""
+ echo "...Uh oh, there is a problem."
+ echo "You don't have a db/ subdirectory here."
+ echo "Please get berkely DB ${DB_WANTED} from:"
+ echo " ${DB_URL}"
+ echo ""
+ echo "Unpack the archive using tar/gunzip and rename the resulting"
+ echo "directory from ./db-${NEON_WANTED}/ to ./db/"
+ echo ""
+ exit 1
+fi
+
+DB_VERSION=`ac-helpers/get-db-ver.sh db`
+if test "$DB_WANTED" != "$DB_VERSION"; then
+ echo ""
+ echo "...Uh oh, there is a problem."
+ echo "You have a db/ subdir containing version $DB_VERSION,"
+ echo "but Subversion needs ${DB_WANTED}."
+ echo "Please get berkely DB ${DB_WANTED} from:"
+ echo " ${DB_URL}"
+ echo ""
+ echo "Unpack the archive using tar/gunzip and rename the resulting"
+ echo "directory from ./db-${DB_WANTED}/ to ./db/"
+ echo ""
+ exit 1
+fi
+
+
+
+
# Produce aclocal.m4, so autoconf gets the automake macros it needs
echo "Creating aclocal.m4..."
Index: configure.in
===================================================================
RCS file: /cvs/subversion/configure.in,v
retrieving revision 1.67
diff -u -r1.67 configure.in
--- configure.in 2001/03/02 23:38:20 1.67
+++ configure.in 2001/03/05 08:10:56
@@ -44,6 +44,13 @@
if test "$enable_subdir_config" = "yes"; then
APR_SUBDIR_CONFIG(apr)
APR_SUBDIR_CONFIG(neon, --with-expat="$abs_srcdir/expat-lite/libexpat.la")
+
+ if test -d $abs_srcdir/db ; then
+ APR_SUBDIR_CONFIG(db/dist)
+ # Note: DB_SUBDIR is used in subversion/Makefile.am only
+ DB_SUBDIR=db/dist
+ fi
+ AC_SUBST(DB_SUBDIR)
fi
@@ -260,7 +267,7 @@
the Subversion filesystem library, part of
-the server, requires Berkeley DB version 3.1.14 or newer, which you
+the server, requires Berkeley DB version 3.2.9 or newer, which you
don't seem to have installed. We have created makefiles which will
build the Subversion client code only, and skip the server.
You can find latest version of Berkeley DB at http://www.sleepycat.com.])
Index: ac-helpers/berkeley-db.m4
===================================================================
RCS file: /cvs/subversion/ac-helpers/berkeley-db.m4,v
retrieving revision 1.6
diff -u -r1.6 berkeley-db.m4
--- ac-helpers/berkeley-db.m4 2001/03/02 23:38:22 1.6
+++ ac-helpers/berkeley-db.m4 2001/03/05 08:10:57
@@ -71,11 +71,32 @@
fi
],
[
- status=if-found
- places=search
+ # No --with-berkeley-db option:
+ #
+ # Check to see if a db directory exists in the build directory.
+ # If it does then we will be using the berkeley DB version
+ # from the source tree. We can't test it since it is not built
+ # yet, so we have to assume it is the correct version.
+
+ AC_MSG_CHECKING([for built-in Berkeley DB])
+
+ if test -d db ; then
+ status=builtin
+ AC_MSG_RESULT([yes])
+ else
+ status=if-found
+ places=search
+ AC_MSG_RESULT([no])
+ fi
])
- if test "$status" = "skip"; then
+ if test "$status" = "builtin"; then
+ # Use the include a nd lib files in the build dir.
+ dbdir=`cd db/dist ; pwd`
+ CPPFLAGS="$CPPFLAGS -I$dbdir"
+ LIBS="$LIBS -L$dbdir -ldb"
+ svn_lib_berkeley_db=yes
+ elif test "$status" = "skip"; then
svn_lib_berkeley_db=no
else
Re: Patch to build db in the tree.
Posted by su...@thewrittenword.com.
On Mon, Mar 05, 2001 at 03:37:57PM -0800, Mo DeJong wrote:
> On 5 Mar 2001, Karl Fogel wrote:
>
> > This sounds like a good idea; will it work like this?:
> >
> > - svn configuration process looks in the svn working copy for the
> > berkeley db sources. If it finds them, it uses them, instead of
> > whatever bdb might happen to be on the system.
> >
> > - If it does not find them, it behaves as it does now.
> >
> > ?,
> > -K
>
> That is how the current patch works. I toyed with the
> idea of requiring a db dir the the subversion tree,
> but I figured someone might object on the grounds
> that they already have a db version installed.
> To be honest, I think it would be better to
> always build with a known db from the source tree,
> but that is really up to you folks.
BTW, how about splitting --with-berkeley-db=PATH out into
--with-berkeley-db-includes=PATH and --with-berkeley-db-libraries=PATH
(taken from DDD). Does anyone else using autoconf do the 'HEADER:LIB'
thing you do with --with-berkeley-db=PATH. I think it's nonstandard.
And, what happens under Windows?
--
albert chin (china@thewrittenword.com)
Re: Patch to build db in the tree.
Posted by Karl Fogel <kf...@galois.collab.net>.
Sam TH <sa...@uchicago.edu> writes:
> Would that it were that easy. Version 2 is a standard system library
> on Debian at least as far back as stable, as it is on RedHat. But
> debian doesn't even have a package for db3. So using the system db
> library isn't really an option. =20
>
> And anyway, don't we require 3.2.9 now?
Yeah; Debian et al will catch up eventually. Sleepycat just released
3.2.9.
Re: Patch to build db in the tree.
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Sam TH <sa...@uchicago.edu> writes:
> >
> > 1. Many systems come with Berkeley DB pre-installed; among the
> > free Unices, it's pretty much a standard system library, I
> > think.
> >
>
> Would that it were that easy. Version 2 is a standard system library
> on Debian at least as far back as stable, as it is on RedHat. But
> debian doesn't even have a package for db3. So using the system db
> library isn't really an option.
On a brighter note, on my FreeBSD 4.2 box, I got DB 3.2.9 by simply
doing
cd /usr/ports/databases/db3 && make install
So not every system is out of date. :)
> And anyway, don't we require 3.2.9 now?
Sure, but the point is that as db3 version numbers increase, we're
assuming that major interface changes will be relatively rare. We're
assuming that it will be safe to search for 3.2.9 or *greater*. We're
also assuming that 3.2.9 will eventually creep into standard os
distributions at rate -faster- than the rate at which svn absolutely
requires new db3 versions. :)
Re: Patch to build db in the tree.
Posted by Sam TH <sa...@uchicago.edu>.
On Tue, Mar 06, 2001 at 08:40:37AM -0600, Karl Fogel wrote:
> Mo DeJong <md...@cygnus.com> writes:
> > Humm. I was under the impression that neon did not
> > have a public CVS either, how is this any different?
>
> Two differences:
>
> 1. Many systems come with Berkeley DB pre-installed; among the
> free Unices, it's pretty much a standard system library, I
> think.
>
Would that it were that easy. Version 2 is a standard system library
on Debian at least as far back as stable, as it is on RedHat. But
debian doesn't even have a package for db3. So using the system db
library isn't really an option.
And anyway, don't we require 3.2.9 now?
sam th
sam@uchicago.edu
http://www.abisource.com/~sam/
GnuPG Key:
http://www.abisource.com/~sam/key
Re: Patch to build db in the tree.
Posted by Karl Fogel <kf...@galois.collab.net>.
Karl Fogel <kf...@galois.collab.net> writes:
> 2. Subversion is not as sensitive to the BDB version as it is to
> the Neon version. Very likely, any sufficiently recent version
> of Berkeley will work for people trying to build Subversion;
> whereas historically, we've needed to specify the *exact*
> version of Neon to use with a given Subversion tree.
Note: we recently made a change so SVN requires Berkeley 3.2.9 or
higher. But that's a one-time change. Our requirement will probably
remain static at "3.2.9 or higher" for some time.
Re: Patch to build db in the tree.
Posted by Karl Fogel <kf...@galois.collab.net>.
Mo DeJong <md...@cygnus.com> writes:
> Humm. I was under the impression that neon did not
> have a public CVS either, how is this any different?
Two differences:
1. Many systems come with Berkeley DB pre-installed; among the
free Unices, it's pretty much a standard system library, I
think.
2. Subversion is not as sensitive to the BDB version as it is to
the Neon version. Very likely, any sufficiently recent version
of Berkeley will work for people trying to build Subversion;
whereas historically, we've needed to specify the *exact*
version of Neon to use with a given Subversion tree.
> The configure script does that, I was talking about the
> ./autogen.sh script. Again, I just added the error
> in that case to mimic the way neon was setup.
> You could certainly leave the patch to autogen.sh
> out if it was a big deal.
Yeah, I think we should leave that part out.
Thanks for the patch! Ben says he'll take care of it sometime today.
-K
Re: Neon available via read-only CVS
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 06, 2001 at 11:17:27AM -0600, B. W. Fitzpatrick wrote:
>
> > Humm. I was under the impression that neon did not
> > have a public CVS either, how is this any different?
>
> Read-only CVS is available:
>
> $ cvs -d :pserver:anonymous@cvs.red-bean.com:/usr/local/cvs login
> (no password)
> $ cvs -d :pserver:anonymous@cvs.red-bean.com:/usr/local/cvs co neon
>
> A real rsync'ed version of Joe's repository is coming at some point in
> the future at webdav.org... I maintain this one manually as Joe
> releases new versions of neon.
Yah... I've got a fancy shmancy new webdav.org box (a nifty 1U VA Linux 1120
system sponsored by N-Space) colo'd at CollabNet. I'm hoping to move
webdav.org from its temporary location to the new box. It'll pick up a CVS
server and rsync, and Joe said he'd be quite happy to rsync-push his local
CVS repository up to webdav.org.
More news later.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Patch to build db in the tree.
Posted by Mo DeJong <md...@cygnus.com>.
On 6 Mar 2001, Ben Collins-Sussman wrote:
> > That is how the current patch works. I toyed with the
> > idea of requiring a db dir the the subversion tree,
> > but I figured someone might object on the grounds
> > that they already have a db version installed.
>
> That's not the grounds on which Karl and I would object to such a
> requirement. The fact is that users can't check out db3 from a
> public cvs repository. If we were able to display a helpful error
> message that said "please get db3 from cvs with this command...",
> it wouldn't be a big deal. This is what we currently do if apr isn't
> found.
Humm. I was under the impression that neon did not
have a public CVS either, how is this any different?
> > One thing to note is that I added an error msg
> > to the ./autogen.sh script if a db dir could not
> > be found. That assumes that the maintainer
> > is going to use a db directory from the
> > source tree.
>
> This seems to contradict what Karl was requesting; if a db dir
> *isn't* found in the tree, this shouldn't be an error. Configure
> should search for a system installation as usual.
The configure script does that, I was talking about the
./autogen.sh script. Again, I just added the error
in that case to mimic the way neon was setup.
You could certainly leave the patch to autogen.sh
out if it was a big deal.
Mo DeJong
Red Hat Inc
Re: Patch to build db in the tree.
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Mo DeJong <md...@cygnus.com> writes:
> On 5 Mar 2001, Karl Fogel wrote:
>
> > This sounds like a good idea; will it work like this?:
> >
> > - svn configuration process looks in the svn working copy for the
> > berkeley db sources. If it finds them, it uses them, instead of
> > whatever bdb might happen to be on the system.
> >
> > - If it does not find them, it behaves as it does now.
> >
> > ?,
> > -K
>
> That is how the current patch works. I toyed with the
> idea of requiring a db dir the the subversion tree,
> but I figured someone might object on the grounds
> that they already have a db version installed.
That's not the grounds on which Karl and I would object to such a
requirement. The fact is that users can't check out db3 from a
public cvs repository. If we were able to display a helpful error
message that said "please get db3 from cvs with this command...",
it wouldn't be a big deal. This is what we currently do if apr isn't
found.
> One thing to note is that I added an error msg
> to the ./autogen.sh script if a db dir could not
> be found. That assumes that the maintainer
> is going to use a db directory from the
> source tree.
This seems to contradict what Karl was requesting; if a db dir
*isn't* found in the tree, this shouldn't be an error. Configure
should search for a system installation as usual.
Re: Patch to build db in the tree.
Posted by Mo DeJong <md...@cygnus.com>.
On 5 Mar 2001, Karl Fogel wrote:
> This sounds like a good idea; will it work like this?:
>
> - svn configuration process looks in the svn working copy for the
> berkeley db sources. If it finds them, it uses them, instead of
> whatever bdb might happen to be on the system.
>
> - If it does not find them, it behaves as it does now.
>
> ?,
> -K
That is how the current patch works. I toyed with the
idea of requiring a db dir the the subversion tree,
but I figured someone might object on the grounds
that they already have a db version installed.
To be honest, I think it would be better to
always build with a known db from the source tree,
but that is really up to you folks.
One thing to note is that I added an error msg
to the ./autogen.sh script if a db dir could not
be found. That assumes that the maintainer
is going to use a db directory from the
source tree. A person packaging up a .tar ball
could always delete the db dir after running
./autogen.sh if size was an issue. The db
dir includes a lot of interfaces that we
are not going to make use of (Tcl, Java, C++,
Perl, and others).
Mo DeJong
Red Hat Inc
Re: Patch to build db in the tree.
Posted by Karl Fogel <kf...@galois.collab.net>.
This sounds like a good idea; will it work like this?:
- svn configuration process looks in the svn working copy for the
berkeley db sources. If it finds them, it uses them, instead of
whatever bdb might happen to be on the system.
- If it does not find them, it behaves as it does now.
?,
-K
Mo DeJong <md...@cygnus.com> writes:
> Hi all.
>
> So it seems that most folks are
> going to need to build an updated
> version of Berkeley DB for use
> with subversion. I have a Red Hat
> 6.2 box and it appears that my
> version of Berkeley DB is too
> old for subversion :(
>
> Since we need to build it,
> I decided to add db to the
> subversion top-level configure
> by duplicating how neon is
> integrated.
>
>
> Why build our own Berkeley DB?
>
> (1) Every developer should be
> running the exact same code.
>
> There has already been one example
> where different versions of the
> db lib have caused problems.
> Statically linking in a known
> version of Berkeley DB is the
> best way to make sure nobody
> get bitten by some odd little
> bug caused by version conflicts.
>
>
> (2) Building subversion should
> be easy.
>
> It is really critical that
> folks are able to build with
> a minimum of fuss. Folks
> don't want to go download
> and build a bunch of stuff.
> One toplevel configure
> should do it all for them.
>
> We should concern ourselves
> with making it easy for joe
> developer out there to get
> subversion built with the
> minimum of fuss.
>
> Distribution builders
> and power users can always
> use an existing library via
> the --with-berkeley-db switch.
>
>
> (3) The client side fs should build
> by default.
>
> The default build should support
> a local filesystem as well as
> a networked interface. Currently,
> the local fs code will not get
> built if a good version of db
> can not be found on the system.
>
>
> Unknowns:
>
> Is db-3.2.9 the right version?
>
> Should the default db configure
> be static? We would need to
> pass the --enable-dynamic
> option to db's configure
> script to enable shared libs.
>
> Shared libs are a bit more
> dangerous since they are
> harder to build/debug and
> more can go wrong. On the
> other hand svn libs are
> currently being built shared.
>
> Should the --enable-debug or
> --enable-posixmutexes flags
> be passed to db's configure?
>
> Should the db dir be required?
> This patch will build the
> old way if the db subdir
> is not in the tree or if
> another location is passed
> via the --with-berkeley-db
> switch.
>
>
> cheers
> Mo DeJong
> Red Hat Inc
>
>
>
>
> 2001-03-04 Mo DeJong <md...@redhat.com>
>
> * Makefile.am: Add DB_DUBDIR to SUBDIRS.
> DB_SUBDIR is empty when db is not built
> in the subversion tree.
> * autogen.sh: Add gen time check for
> db subdir.
> * configure.in: Configure in the db
> subdir if it exists.
> * ac-helpers/berkeley-db.m4: Add
> new builtin status. It will set the
> flags to use the db dir in the
> build directory.
> * ac-helpers/get-db-ver.sh: Add
> script to determine the version
> of the db package in the srcdir.
>
>
>
> (New File)
>
> % cat ac-helpers/get-db-ver.sh
> #! /bin/sh
> #
> # USAGE: get-db-ver.sh DIRECTORY
> #
>
> conf=$1/dist/RELEASE
>
> # Tested with the 3.2.9 release from Sleepycat
>
> major=`sed -n '/DB_VERSION_MAJOR=/s/.*=//p' $conf`
> minor=`sed -n '/DB_VERSION_MINOR=/s/.*=//p' $conf`
> release=`sed -n '/DB_VERSION_PATCH=/s/.*=//p' $conf`
> echo $major.$minor.$release
>
>
> (Patch files)
>
> Index: Makefile.am
> ===================================================================
> RCS file: /cvs/subversion/Makefile.am,v
> retrieving revision 1.17
> diff -u -r1.17 Makefile.am
> --- Makefile.am 2001/02/05 19:21:25 1.17
> +++ Makefile.am 2001/03/05 08:10:56
> @@ -8,7 +8,7 @@
> ## dependencies between Makefile.am, Makefile.in, and Makefile.
> ## In other words, SUBDIRS does not completely control automake
> ## generation.
> -SUBDIRS = apr expat-lite neon subversion doc
> +SUBDIRS = apr expat-lite neon @DB_SUBDIR@ subversion doc
>
> ACLOCAL = @ACLOCAL@ -I ac-helpers
>
> Index: autogen.sh
> ===================================================================
> RCS file: /cvs/subversion/autogen.sh,v
> retrieving revision 1.36
> diff -u -r1.36 autogen.sh
> --- autogen.sh 2001/02/24 09:09:32 1.36
> +++ autogen.sh 2001/03/05 08:10:56
> @@ -33,12 +33,14 @@
>
> # Handle the neon/ subdir
> NEON_WANTED=0.11.0
> +NEON_URL="http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
> +
> if [ ! -d neon ]; then
> echo ""
> echo "...Uh oh, there is a problem."
> echo "You don't have a neon/ subdirectory here."
> echo "Please get neon ${NEON_WANTED} from:"
> - echo " http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
> + echo " ${NEON_URL}"
> echo ""
> echo "Unpack the archive using tar/gunzip and rename the resulting"
> echo "directory from ./neon-${NEON_WANTED}/ to ./neon/"
> @@ -52,13 +54,50 @@
> echo "You have a neon/ subdir containing version $NEON_VERSION,"
> echo "but Subversion needs neon ${NEON_WANTED}."
> echo "Please get neon ${NEON_WANTED} from:"
> - echo " http://www.webdav.org/neon/neon-${NEON_WANTED}.tar.gz"
> + echo " ${NEON_URL}"
> echo ""
> echo "Unpack the archive using tar/gunzip and rename the resulting"
> echo "directory from ./neon-${NEON_WANTED}/ to ./neon/"
> echo ""
> exit 1
> fi
> +
> +
> +# Handle the db/ subdir
> +DB_WANTED=3.2.9
> +DB_URL="http://www.sleepycat.com/update/3.2.9/db-3.2.9.tar.gz"
> +
> +if [ ! -d db ]; then
> + echo ""
> + echo "...Uh oh, there is a problem."
> + echo "You don't have a db/ subdirectory here."
> + echo "Please get berkely DB ${DB_WANTED} from:"
> + echo " ${DB_URL}"
> + echo ""
> + echo "Unpack the archive using tar/gunzip and rename the resulting"
> + echo "directory from ./db-${NEON_WANTED}/ to ./db/"
> + echo ""
> + exit 1
> +fi
> +
> +DB_VERSION=`ac-helpers/get-db-ver.sh db`
> +if test "$DB_WANTED" != "$DB_VERSION"; then
> + echo ""
> + echo "...Uh oh, there is a problem."
> + echo "You have a db/ subdir containing version $DB_VERSION,"
> + echo "but Subversion needs ${DB_WANTED}."
> + echo "Please get berkely DB ${DB_WANTED} from:"
> + echo " ${DB_URL}"
> + echo ""
> + echo "Unpack the archive using tar/gunzip and rename the resulting"
> + echo "directory from ./db-${DB_WANTED}/ to ./db/"
> + echo ""
> + exit 1
> +fi
> +
> +
> +
> +
>
> # Produce aclocal.m4, so autoconf gets the automake macros it needs
> echo "Creating aclocal.m4..."
> Index: configure.in
> ===================================================================
> RCS file: /cvs/subversion/configure.in,v
> retrieving revision 1.67
> diff -u -r1.67 configure.in
> --- configure.in 2001/03/02 23:38:20 1.67
> +++ configure.in 2001/03/05 08:10:56
> @@ -44,6 +44,13 @@
> if test "$enable_subdir_config" = "yes"; then
> APR_SUBDIR_CONFIG(apr)
> APR_SUBDIR_CONFIG(neon, --with-expat="$abs_srcdir/expat-lite/libexpat.la")
> +
> + if test -d $abs_srcdir/db ; then
> + APR_SUBDIR_CONFIG(db/dist)
> + # Note: DB_SUBDIR is used in subversion/Makefile.am only
> + DB_SUBDIR=db/dist
> + fi
> + AC_SUBST(DB_SUBDIR)
> fi
>
>
> @@ -260,7 +267,7 @@
>
>
> the Subversion filesystem library, part of
> -the server, requires Berkeley DB version 3.1.14 or newer, which you
> +the server, requires Berkeley DB version 3.2.9 or newer, which you
> don't seem to have installed. We have created makefiles which will
> build the Subversion client code only, and skip the server.
> You can find latest version of Berkeley DB at http://www.sleepycat.com.])
> Index: ac-helpers/berkeley-db.m4
> ===================================================================
> RCS file: /cvs/subversion/ac-helpers/berkeley-db.m4,v
> retrieving revision 1.6
> diff -u -r1.6 berkeley-db.m4
> --- ac-helpers/berkeley-db.m4 2001/03/02 23:38:22 1.6
> +++ ac-helpers/berkeley-db.m4 2001/03/05 08:10:57
> @@ -71,11 +71,32 @@
> fi
> ],
> [
> - status=if-found
> - places=search
> + # No --with-berkeley-db option:
> + #
> + # Check to see if a db directory exists in the build directory.
> + # If it does then we will be using the berkeley DB version
> + # from the source tree. We can't test it since it is not built
> + # yet, so we have to assume it is the correct version.
> +
> + AC_MSG_CHECKING([for built-in Berkeley DB])
> +
> + if test -d db ; then
> + status=builtin
> + AC_MSG_RESULT([yes])
> + else
> + status=if-found
> + places=search
> + AC_MSG_RESULT([no])
> + fi
> ])
>
> - if test "$status" = "skip"; then
> + if test "$status" = "builtin"; then
> + # Use the include a nd lib files in the build dir.
> + dbdir=`cd db/dist ; pwd`
> + CPPFLAGS="$CPPFLAGS -I$dbdir"
> + LIBS="$LIBS -L$dbdir -ldb"
> + svn_lib_berkeley_db=yes
> + elif test "$status" = "skip"; then
> svn_lib_berkeley_db=no
> else
>