RE: Cvs2svn dies with "dbm.error: cannot add item to database"

Regarding repository portability... My converted repository appears to
work correctly as cvs2svn created it on the Linux machine. When I moved
the CVS repository back to the Solaris machine, I got errors such as:

>svn co
file:///$HOME/tmp/test_svn/repos/trunk/webcenter/prod/htdocs/payroll
svn: Couldn't open a repository.
svn: Unable to open an ra_local session to URL
svn: Unable to open repository
'file:////export/gjohnson/tmp/test_svn/repos/trunk/webcenter/prod/htdocs
/payroll'
svn: Berkeley DB error
svn: Berkeley DB error while opening environment for filesystem
//export/gjohnson/tmp/test_svn/repos/db:
DB_RUNRECOVERY: Fatal error, run database recovery

I then tried this...

>svnadmin recover repos
Acquiring exclusive lock on repository db.
Recovery is running, please stand by...svn: Berkeley DB error
svn: DB_RUNRECOVERY: Fatal error, run database recovery

Then this...

>/export/gjohnson/local/BerkeleyDB.4.1/bin/db_recover
 -h /export/gjohnson/tmp/test_svn/repos/db
db_recover: Ignoring log file:
/export/gjohnson/tmp/test_svn/repos/db/log.0000000358: magic number
88090400, not 40988
db_recover: Invalid log file: log.0000000358: Invalid argument
db_recover: PANIC: Invalid argument
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: fatal region error detected; run recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database
recovery

I found that if I move the log files (log.0000000001 through
log.0000000358) from db to somewhere else, the repository then works
fine.

I'm not sure I can safely remove these log files, though, because I
noticed that subsequent log files created aren't quite right. Once a
new log.0000000001 is created, I get:

>$HOME/local/BerkeleyDB.4.1/bin/db_recover -h db -v
db_recover: Finding last valid log LSN: file: 1 offset 28571
db_recover: Recovery starting from [1][28]
db_recover: Log sequence error: page LSN 1 1034; previous LSN 1 83009
db_recover: Log sequence error: page LSN 1 27773; previous LSN 1 105302
[numerous similar lines deleted]
db_recover: DB_ENV->log_flush: LSN past current end-of-log
db_recover: representations: unable to flush page: 0
db_recover: txn_checkpoint: failed to flush the buffer cache Invalid
argument
db_recover: PANIC: Invalid argument
db_recover: fatal region error detected; run recovery
db_recover: fatal region error detected; run recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database
recovery

I'm guessing there is a portability problem with the format of the
1...358 log files, since they don't cause any problems on the Linux
machine:

>$HOME/local/BerkeleyDB.4.1/bin/db_recover -h db -v
db_recover: Finding last valid log LSN: file: 358 offset 711916
db_recover: Recovery starting from [358][521481]
db_recover: Recovery complete at Wed Jul 2 12:05:36 2003
db_recover: Maximum transaction ID 800dd408 Recovery checkpoint
[358][711916]
db_recover: Recovery complete at Wed Jul 2 12:05:36 2003
db_recover: Maximum transaction id 80000000 Recovery checkpoint
[358][711916]

The version of BerkeleyDB on both machines is "Sleepycat Software:
Berkeley DB 4.1.25: (December 19, 2002)".

Suggestions? Are these log files supposed to be portable? Is there a
way to remove the 1...358 log files and have it start over correctly
with the new log.0000000001, or would that just be ignoring bigger
problems?

--
Graham Johnson
gjohnson@alpineaccess.com
-----Original Message-----
From: kfogel@collab.net [mailto:kfogel@collab.net] 
Sent: Tuesday, July 01, 2003 8:03 PM
To: Johnson, Graham
Cc: dev@subversion.tigris.org
Subject: Re: Cvs2svn dies with "dbm.error: cannot add item to database"
"Johnson, Graham" <gjohnson@alpineaccess.com> writes:
> On RedHat, cvs2svn is chugging along fine on my repository, currently 
> being several passes "------- Committed revision 2798 >>>..." beyond 
> where it was failing on the Solaris machine.
> 
> Assuming the repository will be portable between Linux and Solaris, I 
> can accept doing migrations (for testing and presumably for an 
> eventual final migration) on the Linux machine and moving the 
> repository.
Your CVS repository should always be portable between machines, yes.
> I'm willing to provide any assistance/information needed to figure out
> why it is failing on the Solaris machine.  We don't know, though, that
> the problem isn't specific to this one machine or to how I installed 
> things.
Well, we've got enough to work on in cvs2svn that I feel no need to go
looking for trouble.  But if it happens to someone else, we should try
to triangulate on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org