You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/05/04 22:38:43 UTC
UpPgrading BDB repositories on Win32
I'm fiddling with the README.txt file for the 1.2 Win32 binaries,
because I want to include instructions for upgrading BDB repositories
(1.1.x uses BDB 4.2, 1.2.x uses BDB 4.3). I've come up with the
following procedure:
----------
In this release, we've upgraded BerkeleyDB from version 4.2.52 to
4.3.27. If you are currently using Subversion 1.1.x as a server on
Windows with BerkeleyDB, use the following steps to upgrade your
repositories:
-- Make sure nobody is using the repository (stop Apache/svnserve,
restrict access via file://).
-- Using the old (1.1.x) binaries, run "svnadmin recover" for
each repository.
-- Using the new (1.2.x) binares, for each repository:
-- run "svnlook youngest"
-- run "svnadmin recover"
Once again, this is only necessary for repositories based on BDB.
You do NOT have to dump/reload your repositories.
----------
This seems to work in my tests. However, I'm seriously puzzled by the
need to run "svnlook" before "svnadmin recover" with the new binaries.
Recover by itself will choke, with the following error:
----------
Repository lock acquired.
Please wait; recovering the repository may take some time...
svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
svnadmin: bdb: Program version 4.3 doesn't match environment version
svnadmin: bdb: Skipping log file repo/db\log.0000000001: historic log version 8
svnadmin: bdb: repo/db\log.0000000002: log file open failed: No such file or directory
svnadmin: bdb: PANIC: No such file or directory
svnadmin: bdb: DB_ENV->log_put: 2: DB_RUNRECOVERY: Fatal error, run database recovery
----------
I'm inclined to call this a bug in svnadmin recover, but I'm not sure
how to start fixing it.
Any ideas?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>So, it seems that the following procedure should work:
>>
>>--------
>> -- Make sure nobody is using the repository (stop Apache/svnserve,
>> restrict access via file://).
>> -- For each repository, using the old (1.1.x) binaries:
>> -- Run "svnadmin recover <repos-dir>";
>> -- Create a backup of the repository;
>> -- Run "svnadmin list-unused-dblogs <repos-dir>"
>> and remove the listed files;
>> -- Delete all the "<repos-dir>\db\__db.00?" files.
>> -- Upgrade Subversion.
>>--------
>>
>>
>
>That works, but only if I back out my error printing patch. So it
>leaves the problem that the remaining 4.2 log file will sometimes
>cause BDB to call bdb_error_gatherer() and so generate svn_error_t
>errors that never get cleared. I'm currently using the following to
>clear and ignore such errors:
>
>
[snip]
This patch looks fine to me, and IMHO should be ported to 1.2.x, too.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> So, it seems that the following procedure should work:
>
> --------
> -- Make sure nobody is using the repository (stop Apache/svnserve,
> restrict access via file://).
> -- For each repository, using the old (1.1.x) binaries:
> -- Run "svnadmin recover <repos-dir>";
> -- Create a backup of the repository;
> -- Run "svnadmin list-unused-dblogs <repos-dir>"
> and remove the listed files;
> -- Delete all the "<repos-dir>\db\__db.00?" files.
> -- Upgrade Subversion.
> --------
That works, but only if I back out my error printing patch. So it
leaves the problem that the remaining 4.2 log file will sometimes
cause BDB to call bdb_error_gatherer() and so generate svn_error_t
errors that never get cleared. I'm currently using the following to
clear and ignore such errors:
Index: subversion/libsvn_fs_base/bdb/bdb-err.c
===================================================================
--- subversion/libsvn_fs_base/bdb/bdb-err.c (revision 14573)
+++ subversion/libsvn_fs_base/bdb/bdb-err.c (working copy)
@@ -86,10 +86,14 @@
svn_error_t *
svn_fs_bdb__wrap_db (svn_fs_t *fs, const char *operation, int db_err)
{
- base_fs_data_t *bfd;
+ base_fs_data_t *bfd = fs->fsap_data;
if (! db_err)
- return SVN_NO_ERROR;
+ {
+ svn_error_clear (bfd->errcall_baton->pending_errors);
+ bfd->errcall_baton->pending_errors = NULL;
+ return SVN_NO_ERROR;
+ }
bfd = fs->fsap_data;
return svn_fs_bdb__dberrf
Index: subversion/libsvn_fs_base/bdb/bdb-err.h
===================================================================
--- subversion/libsvn_fs_base/bdb/bdb-err.h (revision 14573)
+++ subversion/libsvn_fs_base/bdb/bdb-err.h (working copy)
@@ -78,6 +78,8 @@
int db_err__temp = (expr); \
if (db_err__temp) \
return svn_fs_bdb__dberr ((ec_baton), db_err__temp); \
+ svn_error_clear (ec_baton->pending_errors); \
+ ec_baton->pending_errors = NULL; \
} while (0)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On May 5, 2005, at 5:26 PM, Branko Čibej wrote:
>>
>> --------
>> -- Make sure nobody is using the repository (stop Apache/svnserve,
>> restrict access via file://).
>> -- For each repository, using the old (1.1.x) binaries:
>> -- Run "svnadmin recover <repos-dir>";
>> -- Create a backup of the repository;
>> -- Run "svnadmin list-unused-dblogs <repos-dir>"
>> and remove the listed files;
>> -- Delete all the "<repos-dir>\db\__db.00?" files.
>> -- Upgrade Subversion.
>> --------
>>
>
> I'm a bit unclear on the resolution of this mail thread.
>
> * Is this the final BDB 4.2->4.3 upgrade procedure we're prescribing?
>
> * Is it only necessary on Windows?
>
> * If so, this is a releasenote about Branko's win32 binaries,
> only, right? Given that, where should we post this procedure?
It is necessary on any OS, when going from 4.2->4.3. The Windows-specific
element is that we provide Windows binaries, and thus promulgate a
recommended version of BDB, whereas for all other OSes, we just use whatever
is present in the distribution.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 14, 2005, at 11:25 AM, Branko Čibej wrote:
>
> It's in the README in the Win32 binary package, mainly because I
> upgraded BDB from the 1.1.x to 1.2.x line. Most people who use SVN
> on Windows probably use those binaries, so they'll need to upgrade
> their BDB repositories.
>
OK, so that explains why we saw a Mandrake user get burned by this
same problem.
It's a pretty big deal, then. And we need to document this is a
prominent place, probably our FAQ. And then put promient pointers
to it, probably in the final 1.2 release announcement email, and in
the 1.2 releasenotes.
Do folks agree? If so, I volunteer to do it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On May 5, 2005, at 5:26 PM, Branko Čibej wrote:
>
>>
>> --------
>> -- Make sure nobody is using the repository (stop Apache/svnserve,
>> restrict access via file://).
>> -- For each repository, using the old (1.1.x) binaries:
>> -- Run "svnadmin recover <repos-dir>";
>> -- Create a backup of the repository;
>> -- Run "svnadmin list-unused-dblogs <repos-dir>"
>> and remove the listed files;
>> -- Delete all the "<repos-dir>\db\__db.00?" files.
>> -- Upgrade Subversion.
>> --------
>>
>
> I'm a bit unclear on the resolution of this mail thread.
>
> * Is this the final BDB 4.2->4.3 upgrade procedure we're prescribing?
It's one that works. Philip and I both tried it, then I added the bits
about backing up the repository and removing unused logs.
> * Is it only necessary on Windows?
No, everywhere.
> * If so, this is a releasenote about Branko's win32 binaries, only,
> right? Given that, where should we post this procedure?
It's in the README in the Win32 binary package, mainly because I
upgraded BDB from the 1.1.x to 1.2.x line. Most people who use SVN on
Windows probably use those binaries, so they'll need to upgrade their
BDB repositories.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 5, 2005, at 5:26 PM, Branko Čibej wrote:
>
> --------
> -- Make sure nobody is using the repository (stop Apache/svnserve,
> restrict access via file://).
> -- For each repository, using the old (1.1.x) binaries:
> -- Run "svnadmin recover <repos-dir>";
> -- Create a backup of the repository;
> -- Run "svnadmin list-unused-dblogs <repos-dir>"
> and remove the listed files;
> -- Delete all the "<repos-dir>\db\__db.00?" files.
> -- Upgrade Subversion.
> --------
>
I'm a bit unclear on the resolution of this mail thread.
* Is this the final BDB 4.2->4.3 upgrade procedure we're prescribing?
* Is it only necessary on Windows?
* If so, this is a releasenote about Branko's win32 binaries,
only, right? Given that, where should we post this procedure?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
So, it seems that the following procedure should work:
--------
-- Make sure nobody is using the repository (stop Apache/svnserve,
restrict access via file://).
-- For each repository, using the old (1.1.x) binaries:
-- Run "svnadmin recover <repos-dir>";
-- Create a backup of the repository;
-- Run "svnadmin list-unused-dblogs <repos-dir>"
and remove the listed files;
-- Delete all the "<repos-dir>\db\__db.00?" files.
-- Upgrade Subversion.
--------
I'm slightly pissed off about having to remove the environment files
manually, but bugs will be bugs...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>Philip Martin wrote:
>>
>>
>>
>>>The upgrade procedure that seems to work on my test repository is:
>>>
>>>- run 'svnadmin recover' using BDB 4.2
>>>- remove db/_db.00?
>>>
>>>
>>>
>>Well, there's a bug right there in "svnadmin recover", then. It should
>>remove the environment files itself.
>>
>>
>
>svn_repos_recover2() does remove the environment, however
>'svnadmin recover' open the recovered repository to read the
>youngest revision and so the environment is recreated.
>
>
Ah. You're right, I missed that part. So /that/ is the bug in "svnadmin
recover". It's sheer nonsense keep the old-format environment files
around when you recover the database, becasue that will always make the
newer version of BDB choke. In other words, "svnadmin recover" as it
stands now is useless for upgrading BDB repositories.
>>>- remove or archive db/log.*
>>>
>>>
>>>
>>>
>>Ouch! This is *not* good.
>>
>>
>>
>>>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>>>although it doesn't do any harm. Note that I have to remove all the
>>>log files, even those not designated "unused", I don't know under
>>>what circumstances this is safe.
>>>
>>>
>>>
>>Never, according to the BDB docs.
>>
>>
>
>4.3 recovery doesn't work with 4.2 log files, even using native BDB
>tools.
>
Yes. But read my other post: The DB docs say to recover with the old
version, but _not_ with the new version, and to leave the logs alone.
Just remove the unused logs, and start using the database. I suppose
that's why doing "svnlook youngest" before using the new svnadmin
recover usually works.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Philip Martin wrote:
>
>>The upgrade procedure that seems to work on my test repository is:
>>
>>- run 'svnadmin recover' using BDB 4.2
>>- remove db/_db.00?
>>
> Well, there's a bug right there in "svnadmin recover", then. It should
> remove the environment files itself.
svn_repos_recover2() does remove the environment, however
'svnadmin recover' open the recovered repository to read the
youngest revision and so the environment is recreated.
>>- remove or archive db/log.*
>>
>>
> Ouch! This is *not* good.
>
>>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>>although it doesn't do any harm. Note that I have to remove all the
>>log files, even those not designated "unused", I don't know under
>>what circumstances this is safe.
>>
> Never, according to the BDB docs.
4.3 recovery doesn't work with 4.2 log files, even using native BDB
tools. Using BDB 4.2:
$ db4.2_recover -h repo/db/
$ ls repo/db
DB_CONFIG format locks nodes strings
changes fs-type log.0000000001 representations transactions
copies lock-tokens log.0000000002 revisions uuids
$ db4.2_archive -h repo/db/
log.0000000001
$ rm repo/db/log.0000000001
Switch to BDB 4.3:
$ /usr/local/bdb43/bin/db_recover -h repo/db
db_recover: Skipping log file repo/db/log.0000000002: historic log version 8
db_recover: repo/db/log.0000000003: log file open failed: No such file or directory
db_recover: PANIC: No such file or directory
db_recover: DB_ENV->log_put: 3: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: dbenv->close: DB_RUNRECOVERY: Fatal error, run database recovery
$ ls repo/db
DB_CONFIG format locks representations transactions
changes fs-type log.0000000002 revisions uuids
copies lock-tokens nodes strings
$ rm repo/db/log.0000000002
$ /usr/local/bdb43/bin/db_recover -h repo/db
$ ls repo/db
DB_CONFIG format locks representations transactions
changes fs-type log.0000000001 revisions uuids
copies lock-tokens nodes strings
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Philip Martin wrote:
>
>> The upgrade procedure that seems to work on my test repository is:
>>
>> - run 'svnadmin recover' using BDB 4.2
>> - remove db/_db.00?
>>
>>
> Well, there's a bug right there in "svnadmin recover", then. It should
> remove the environment files itself.
And I've found that bug. We were passing both "DB_INIT_LOCK" and
"DB_PRIVATE" when opening the environment for recovery. db_recover does
one _or_ the other, but never both. It uses DB_PRIVATE when it doesn't
want to retain the environment files (and we never want to do that).
>
>> - remove or archive db/log.*
>>
>>
> Ouch! This is *not* good.
The BDB docs say this:
If the application has a Berkeley DB transactional environment, and the
log files need upgrading but the databases do not, the application may
be installed in the field using the following steps:
1. Shut down the old version of the application.
2. Run recovery on the database environment using the DB_ENV->open
<ci...@xbc.nu> method or the db_recover
<ci...@xbc.nu> utility.
3. Remove any Berkeley DB environment using the DB_ENV->remove
<ci...@xbc.nu> method or an appropriate
system utility.
4. Archive the database environment for catastrophic recovery. See
Archival procedures <ci...@xbc.nu> for more
information.
5. Recompile and install the new version of the application.
6. Restart the application.
Step 3. should be happening automatically, but this says nothing about
removing log files that are in use. So I guess doing "svnadmin recover"
and removing the environment files should be enough.
I'll fix svnadmin recover, of couse, and propose the change for backport
to 1.1.x.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Upgrading BDB repositories on Win32
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>The upgrade procedure that seems to work on my test repository is:
>
>- run 'svnadmin recover' using BDB 4.2
>- remove db/_db.00?
>
>
Well, there's a bug right there in "svnadmin recover", then. It should
remove the environment files itself.
>- remove or archive db/log.*
>
>
Ouch! This is *not* good.
>Then just start using BDB 4.3, there is no need to run a 4.3 recover
>although it doesn't do any harm. Note that I have to remove all the
>log files, even those not designated "unused", I don't know under
>what circumstances this is safe.
>
>
Never, according to the BDB docs.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: UpPgrading BDB repositories on Win32
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> I'm fiddling with the README.txt file for the 1.2 Win32 binaries,
> because I want to include instructions for upgrading BDB repositories
> (1.1.x uses BDB 4.2, 1.2.x uses BDB 4.3). I've come up with the
> following procedure:
>
> ----------
> In this release, we've upgraded BerkeleyDB from version 4.2.52 to
> 4.3.27. If you are currently using Subversion 1.1.x as a server on
> Windows with BerkeleyDB, use the following steps to upgrade your
> repositories:
>
> -- Make sure nobody is using the repository (stop Apache/svnserve,
> restrict access via file://).
> -- Using the old (1.1.x) binaries, run "svnadmin recover" for
> each repository.
> -- Using the new (1.2.x) binares, for each repository:
> -- run "svnlook youngest"
> -- run "svnadmin recover"
The BDB docs say that 4.3 undates the log file format, and that seems
to imply that the 1.2.x recover is not required.
>
> Once again, this is only necessary for repositories based on BDB.
> You do NOT have to dump/reload your repositories.
> ----------
>
> This seems to work in my tests. However, I'm seriously puzzled by the
> need to run "svnlook" before "svnadmin recover" with the new
> binaries. Recover by itself will choke, with the following error:
>
> ----------
> Repository lock acquired.
> Please wait; recovering the repository may take some time...
> svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
> svnadmin: bdb: Program version 4.3 doesn't match environment version
> svnadmin: bdb: Skipping log file repo/db\log.0000000001: historic log version 8
> svnadmin: bdb: repo/db\log.0000000002: log file open failed: No such file or directory
> svnadmin: bdb: PANIC: No such file or directory
> svnadmin: bdb: DB_ENV->log_put: 2: DB_RUNRECOVERY: Fatal error, run database recovery
> ----------
>
> I'm inclined to call this a bug in svnadmin recover, but I'm not sure
> how to start fixing it.
This problem is not specific to Windows, it also occurs on my Linux
box. While investigating I discovered that BDB (4.3 at least) will
sometimes call bdb_error_gatherer() but not go on to return an error
status. When this happens an svn_error_t is leaked. I'm using the
following patch which causes those errors to be displayed, (but
perhaps we should just clear them?):
Index: subversion/libsvn_fs_base/bdb/bdb-err.c
===================================================================
--- subversion/libsvn_fs_base/bdb/bdb-err.c (revision 14573)
+++ subversion/libsvn_fs_base/bdb/bdb-err.c (working copy)
@@ -86,9 +86,9 @@
svn_error_t *
svn_fs_bdb__wrap_db (svn_fs_t *fs, const char *operation, int db_err)
{
- base_fs_data_t *bfd;
+ base_fs_data_t *bfd = fs->fsap_data;
- if (! db_err)
+ if (! db_err && ! bfd->errcall_baton->pending_errors)
return SVN_NO_ERROR;
bfd = fs->fsap_data;
Index: subversion/libsvn_fs_base/bdb/bdb-err.h
===================================================================
--- subversion/libsvn_fs_base/bdb/bdb-err.h (revision 14573)
+++ subversion/libsvn_fs_base/bdb/bdb-err.h (working copy)
@@ -76,7 +76,7 @@
#define SVN_BDB_ERR(ec_baton, expr) \
do { \
int db_err__temp = (expr); \
- if (db_err__temp) \
+ if (db_err__temp || ec_baton->pending_errors) \
return svn_fs_bdb__dberr ((ec_baton), db_err__temp); \
} while (0)
Starting with a 4.2 repo:
$ svnadmin recover repo
Repository lock acquired.
Please wait; recovering the repository may take some time...
Recovery completed.
The latest repos revision is 31.
Using 4.3 I get a failure:
$ subversion/svnlook/svnlook youngest repo
../svn/subversion/libsvn_fs_base/bdb/bdb-err.c:76: (apr_err=160029)
svnlook: Berkeley DB error for filesystem repo/db while opening environment:
DB_VERSION_MISMATCH: Database environment version mismatch
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnlook: bdb: Program version 4.3 doesn't match environment version
Running 4.3 recover I get another failure:
$ subversion/svnadmin/svnadmin recover repo
Repository lock acquired.
Please wait; recovering the repository may take some time...
../svn/subversion/libsvn_fs_base/bdb/bdb-err.c:59: (apr_err=160029)
svnadmin: Successful return: 0
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Program version 4.3 doesn't match environment version
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
4.3 still fails:
$ subversion/svnlook/svnlook youngest repo
../svn/subversion/libsvn_fs_base/bdb/bdb-err.c:76: (apr_err=160029)
svnlook: Berkeley DB error for filesystem repo/db while opening environment:
Successful return: 0
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnlook: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
Trying again, 4.3 now works:
$ subversion/svnlook/svnlook youngest repo
31
However running 4.3 recover still fails:
$ subversion/svnadmin/svnadmin recover repo
Repository lock acquired.
Please wait; recovering the repository may take some time...
../svn/subversion/libsvn_fs_base/bdb/bdb-err.c:59: (apr_err=160029)
svnadmin: Successful return: 0
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Skipping log file repo/db/log.0000000001: historic log version 8
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnadmin: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
and that causes svnlook to fail again:
$ subversion/svnlook/svnlook youngest repo
../svn/subversion/libsvn_fs_base/bdb/bdb-err.c:76: (apr_err=160029)
svnlook: Berkeley DB error for filesystem repo/db while opening environment:
Successful return: 0
../svn/subversion/libsvn_fs_base/fs.c:316: (apr_err=0)
svnlook: bdb: Skipping log file repo/db/log.0000000002: historic log version 8
Once again, if I repeat the operation it works:
$ subversion/svnlook/svnlook youngest repo
31
The upgrade procedure that seems to work on my test repository is:
- run 'svnadmin recover' using BDB 4.2
- remove db/_db.00?
- remove or archive db/log.*
Then just start using BDB 4.3, there is no need to run a 4.3 recover
although it doesn't do any harm. Note that I have to remove all the
log files, even those not designated "unused", I don't know under
what circumstances this is safe.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org