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

RE: Repository problems!

From: Mark Bohlman <MBohlman_at_TCICREDIT.COM>
Date: 2003-09-12 20:18:10 CEST

Ben, François,

        Thanks for the responses, am still having problems. Started this
email while
running the dump / load combo and at the end of this email you will see it
failed.

        Did not want to run everyone ragged with upgrades initially, as we
were only
set up to use svnserve, but missed having the userid's on the check-ins, and

waiting for hardware, and real work to do in the interim.... You know how
that
goes I'm sure. Now that we are using only http it should be easier
(although
still have concerns as most of my people use Tortoise as well, which also
requires concurrent upgrades....).

        Permissions on the repository are OK. Running as admin (same id
used
to setup the repository, and run all commands from same id).

        More tidbits of information: Did run DELETE on the offending files
and that failed as well. Then ran DELETE on the directory with the
offending
files and that seems to have worked. Have successfully pulled all files out

of the repository both branches and the trunk. Was able to run a RECOVER
too.

        Then I ran the db_verify against files in the db files and got this
on
------------------[ db verify message
]-----------------------------------------
db_verify: Overflow page 17065 of invalid type
db_verify: DB->verify: strings: DB_VERIFY_BAD: Database verification failed

        Trying to run a dump/load sequence from old (24.2) to new (29)
versions
generated the following:
------------------[ svnadmin(24.2) dump | svnadmin(29)
load]--------------------
the strings file (not sure it is supposed to work correctly on there so...)
     * editing path :
trunk/com.tci.credit/src/com/tci/credit/response/decorator
impl/BRDEquifax.java ... done.
     * editing path :
trunk/com.tci.credit/src/com/tci/credit/response/decorator
impl/BRDExperian.java ... done.
     * editing path :
trunk/com.tci.credit/src/com/tci/credit/response/decorator
impl/BRDTrans_Union.java ... done.
     * editing path :
trunk/com.tci.credit/src/com/tci/credit/response/decorator
impl/GenericBureauResponseDecorator.java ...* Dumped revision 3499.
 done.
------- Committed revision 3499 >>>
<<< Started new txn, based on original revision 3500
     * editing path :
trunk/asp/FraudScreener/src/com/tci/fs/tags/NavigationTag.
java ... done.
svn: Filesystem is corrupt
svn: svn_fs__rep_contents: checksum mismatch on rep "1j1x":
   expected: a8cc345d9885c7cd56b131259b405b2c
     actual: 4c6a3d13af64e40d9985a7225527644d
------- Committed revision 3500 >>>
C:\>
----------------------------[ end of dump-load sequence
]------------------------------

        I "seem" to be able to check everything out OK. I'm concerned that
I may not be
or that I'm actually going to face further problems down the road here. Any
ideas are
appreciated.

Thanks,
        Mark

-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Friday, September 12, 2003 10:56 AM
To: Mark Bohlman
Cc: 'dev@subversion.tigris.org'
Subject: Re: Repository problems!

Mark Bohlman <MBohlman@TCICREDIT.COM> writes:

> Am having a problem with a svn repository (version 24.2 - see
> below).

Oy, why are you using a subversion that is five releases old?? If you
use subversion for real work, please keep it up-to-date! :-)

> svn: REPORT request failed on '/repos/!svn/vcc/default'
> svn:
> svn_fs__rep_contents: checksum mismatch on rep "1j1x":
> expected: a8cc345d9885c7cd56b131259b405b2c
> actual: 4c6a3d13af64e40d9985a7225527644d

That's saying that some data within the database has unexpectedly
changed somehow. Not good.

> I then attempted to run a recovery on the repository and started this at
> 4:45 last
> evening.
> This ran until almost 1 AM today, and generated an error:
> svn: Berkeley DB error
> svn: Permission denied
>
>
> My guess is that we got into a crossed-up situation with the nightly
> backup run (running Veritas Backup Exec 8.5), with each trying to
> grab exclusive locks.

That's a good hypothesis. Why don't you check all the permissions
within repos/db/, and run recovery again....

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 12 20:53:08 2003

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.