You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jim Blandy <ji...@savonarola.red-bean.com> on 2000/08/10 22:12:15 UTC

Berkeley DB in our source tree?

We're going to use Berkeley DB (`Sleepycat') for the filesystem.  It
would be possible to reimplement the stuff it provides for ourselves
(locking, transactions, recovery, etc.) but I don't see any point.
It's very general, and the interfaces are done well.

So, here's my question: should I just import Berkeley DB into our
repository on a vendor branch, or should we simply tell people,
"Install Berkeley DB 3.1.4 before you build Subversion" and stay out
of it?  What would folks prefer?

Re: Berkeley DB in our source tree?

Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > > So, here's my question: should I just import Berkeley DB into our
> > > repository on a vendor branch, or should we simply tell people,
> > > "Install Berkeley DB 3.1.4 before you build Subversion" and stay out
> > > of it?  What would folks prefer?

Let's not make a vendor branch; we should include it with dist
tarballs when we release, though.

The reason to make a vendor branch is when we have local modifications
we need to maintain against the vendor.  Since we don't have such mods
to APR, we don't keep a vendor branch of APR.  But we are using a
modified version of Expat (stripped down, basically), so that's why we
vendor branched it.

autogen.sh should handle Berkeley db the same way it does APR: look
for it, and if not found, tell the user (developer) how to get it.

Re: Berkeley DB in our source tree?

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 10, 2000 at 04:15:46PM -0700, Brian Behlendorf wrote:
> On Thu, 10 Aug 2000, Jim Blandy wrote:
> > So, here's my question: should I just import Berkeley DB into our
> > repository on a vendor branch, or should we simply tell people,
> > "Install Berkeley DB 3.1.4 before you build Subversion" and stay out
> > of it?  What would folks prefer?
> 
> Is Berkeley DB specifically required, or any *dbm?  (gdbm, sdbm, etc)
> 
> Either way, I'm a fan of modularity, so I'd argue for making it an
> external dependency, though I might argue for including it in the
> release tarball.

I'm with Brian: external dependency. I'm not sure whether we'd put it into
our tarball, or just redist the DB tarball.

Note that part of my reluctance on including the source is due to its
licensing. It is similar to the GPL in the way it requires the app to
distribute *all* source (or be subject to Sleepycat licensing fees).

I also view DB as an optional facility. The default, sure, but I would hope
that we could plug in support for other databases (e.g. MySQL).

In other email, somebody asked how this is different from expat-lite.
Licensing for one, the (medium term?) optional nature for two. APR is
included (by reference) in our config/build process (and release tarballs)
simply because it has no other distribution mechanism right now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Berkeley DB in our source tree?

Posted by Jim Blandy <ji...@savonarola.red-bean.com>.
> > > Is Berkeley DB specifically required, or any *dbm?  (gdbm, sdbm, etc)
> > 
> > Berkeley DB is specifically required.  Only Berkeley DB has
> > transactions, recovery, etc.  The other dbm interfaces are toys.
> 
> Are we going to depend on transactions? I would hope that we can avoid them,
> so that we can drop in MySQL at some point.

Well, Berkeley DB transactions are helpful in implementing Subversion
transactions.  Otherwise, you essentially end up re-implementing the
work they've done.  That seems senseless.

Why would it be desireable to switch to MySQL?

Re: Berkeley DB in our source tree?

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 10, 2000 at 06:24:37PM -0500, Jim Blandy wrote:
> 
> > Is Berkeley DB specifically required, or any *dbm?  (gdbm, sdbm, etc)
> 
> Berkeley DB is specifically required.  Only Berkeley DB has
> transactions, recovery, etc.  The other dbm interfaces are toys.

Are we going to depend on transactions? I would hope that we can avoid them,
so that we can drop in MySQL at some point.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Berkeley DB in our source tree?

Posted by Jim Blandy <ji...@savonarola.red-bean.com>.
> Is Berkeley DB specifically required, or any *dbm?  (gdbm, sdbm, etc)

Berkeley DB is specifically required.  Only Berkeley DB has
transactions, recovery, etc.  The other dbm interfaces are toys.

Re: Berkeley DB in our source tree?

Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 10 Aug 2000, Jim Blandy wrote:
> So, here's my question: should I just import Berkeley DB into our
> repository on a vendor branch, or should we simply tell people,
> "Install Berkeley DB 3.1.4 before you build Subversion" and stay out
> of it?  What would folks prefer?

Is Berkeley DB specifically required, or any *dbm?  (gdbm, sdbm, etc)

Either way, I'm a fan of modularity, so I'd argue for making it an
external dependency, though I might argue for including it in the
release tarball.

	Brian