[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Backends...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-01-13 18:07:29 CET

On Jan 13, 2005, at 10:53 AM, Brad wrote:

> I agree this is very dangerous idea, separation of layers is valid
> concern. We will probably just end up storing all our metadata in the
> oracle tables and leave subversion to simply do what it is meant for.
> Do you see fsfs becoming the standard for subversion? Is there any
> work being down using alternate backends?

That's a loaded question. :-)

There are many opinions on this. For a while, people have been getting
frustrated with BDB's sensitivity to interruptions, and having to run
recovery. FSFS is definitely a reaction to that. On the dev@ list,
there's long been an unspoken idea floating around: "well, assuming
FSFS turns out to be really stable, and assuming that we can't make BDB
friendlier for users, we might end up making FSFS the default back end,
and ultimately retire BDB."

But then Sleepycat showed up recently, and they're rightfully annoyed
that BDB is indirectly getting a bad reputation through people's
exposure to it in Subversion. Now we're actively working with them to
make things better. It turns out that Subversion is using BDB in a
unique way... so these are issues that Sleepycat hasn't had to deal
with before. While there's really no way to make BDB less sensitive to
interruptions, there *are* things we can do to make BDB auto-recover
itself upon next access. So it looks like our BDB headaches may soon
go away, if things work out.

My prediction is that both back-ends will enjoy a long lifetime --
neither one is about to go away anytime soon.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 13 18:11:07 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.