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

Re: Coping with BerkeleyDB Upgrades

From: Mark Reibert <svn_at_reibert.com>
Date: Mon, 31 Aug 2009 22:20:27 -0700

Hi Rich,

I too have been using SVN since the days when BDB was the default.
Personally, I think one of the best arguments for FSFS is simply to
avoid this kind of BDB dependency problem.

There are a couple of ways to handle this:

1. If you can get the old BDB (and SVN) back, dump the repo then load it
into a new FSFS repo (using the new SVN).

2. If 1 is not an option, something like what is discussed at
http://svn.haxx.se/users/archive-2004-09/1184.shtml might help. This is
pretty old, but the concepts might still apply to your situation.

I needed to do the manual upgrade noted in option #2 once, and shortly
thereafter all my repos became FSFS!

Regards,
Mark

On Mon, 2009-08-31 at 07:14 -0700, Rich Shepard wrote:
> On Sun, 30 Aug 2009, Mark Reibert wrote:
>
> > Use the FSFS backend, which has been the default for "svnadmin create"
> > for quite some time.
>
> Mark,
>
> Apparently I used Subversion-1.0 or -1.1 to create the repository in 2005
> and the default then was Berkeley DB.
>
> Now it's using the FSFS back end.
>
> Thanks,
>
> Rich
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388907
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

-- 
----------------------
Mark S. Reibert, Ph.D.
svn_at_reibert.com
----------------------
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389651
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-01 07:21:27 CEST

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.