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

Re: is this a known error?

From: Peter Hercek <peter_at_syncad.com>
Date: 2005-06-24 20:07:30 CEST

C. Michael Pilato wrote:
> Peter Hercek <peter@syncad.com> writes:
>>Does anybody know how to dump part of repository with its history?
>> The command should take url within existing repository (not url
>> of the whole repository). E.g. I want to export everything in
>> svn://svn/temp_tags/peter with all its history; i.e. if the
>> repository contains svn://svn/trunk/src and the files in trunk/src do
>> not have anything in common (even in their history) with temp_tags
>> (and their history) then no data from trunk/src would get out to
>> the dump.
> Have you explored the use of the svndumpfilter?

Well, not before you told us. Thanks for the tip.
But before we can try it we must get dump working first.
So far we are getting errors like e.g. this one:

* Dumped revision 9350.
svnadmin: Berkeley DB error for filesystem us-30884/db while reading copy:
DB_RUNRECOVERY: Fatal error, run database recovery
svnadmin: bdb: page 1111628668: illegal page type or format
svnadmin: bdb: PANIC: Invalid argument
svnadmin: Berkeley DB error for filesystem us-30884/db while closing 'nodes'
DB_RUNRECOVERY: Fatal error, run database recovery
svnadmin: bdb: PANIC: fatal region error detected; run recovery

Recovery does not fix this error. It reports that it finished
  and everything is ok, but when we launch dump again we get
  exactly the same error at the same place.

We should be able to fix this from older dump file we have
  archived and which are known to be correct. Our Berkeley DB
  repository is a bit bigger - about 4.5 GiB. So these things
  will take some time.

We had problems with RAID controller there, so it could happen
  that the db got broaken because of the controller and not
  svn itself. We run recovery at that time. It finished ok,
  but (in the light of our current experience) it probably does
  not mean much.

Still, I suppose this is not the same problem as the merge
  failure since the merge worked ok when done in parts.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 24 20:10:26 2005

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

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