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

RE: My repository is buggered?

From: Stuart Celarier <SCelarier_at_corillian.com>
Date: 2006-06-05 15:47:03 CEST

> I'm pretty sure it's BDB (I'm pretty new at this admin stuff but a
> veteran of using svn as a developer)

I'm sure there are more definitive ways to tell, but look in the
README.txt file in the root directory of the repository. On a BDB
repository, this file contains the paragraph:

"The directory "db" contains a Berkeley DB environment,
you may need to tweak the values in "db/DB_CONFIG" to match the
requirements of your site."

On an FSFS repository, there is no such wording.

> I ran svnadmin verify on the server (I control it)
> it said the following:
> svnadmin: Can't open file '/back2/svn/tixrus/trunk/format': No such
> or directory

Not a good omen, but as Ryan pointed out, maybe you've passed in the
wrong parameter to svnadmin verify.

> I didn't hack the repository itself only my working copy. In retro,
> probably wasn't such a great idea. I suspect it checks dates and
> filestamps to guard against this kind of thing.

An relational integrity of the disconnected dataset. Treat .svn folders
as a black box.

> > You do back up your repositories, correct?
> I hope to shout. I pay a backup fee at my colo, they're responsible
> for massive damages if they can't bring back a previous. If I
> though, wouldn't all working copies be invalid and out of synch and is
> there an easy way to synch them?

That's good, but it does sound like you're having the disk backed up,
not (necessarily) a consistent copy of the repository. If one or more
transactions are committed to the repository as the disk image is backed
up, what's in the image? (Answer, you don't really know, and if you're
unlucky, you get copy of a repository in an inconsistent state.)

See the svnadmin hotcopy operation (or hotbackup.py) for making a copy
of the repository that is consistent, even while users are committing

And maybe you're lucky (timing with scheduled backup, small number of
users, phases of the moon) and some of your backed up images are just

Yes, working copies will be invalid. I'd restore the repository to a new
location to emphasize this. Do NOT synchronize working copies from one
repository to a restored repository using svn switch --relocate. I think
the best strategy would be to set the old working copy aside, create a
new working copy the restored repository, and move changes from one
working copy to the other by hand (use svn status on the old wc to
identify the changes without having to use the repository). You will
also need to account for changes made since the backed up repository was

Ideally, people are not accumulating vast changes in their working
copies, but instead committing small, logical changesets. YMMV. So, in
theory, it should not be a big burden to abandon old working copies --
assuming, as you point out, that the repository is not corrupted.

> I was suspicious of the rep being corrupted because I had a
> hard disk fail last week in a raid set. I am not a hardware person
> I thought the whole point of raid was that the system just fails over
> the remaining good disk(s) and that you don't even notice except that
> emails some contact to let you know a drive failed.

I'm also not a hardware person, but there are several levels of RAID
arrays. We use a dedicated RAID 5 array for our repositories, and it
does have the behavior you expect. See
http://www.webopedia.com/TERM/R/RAID.html for more information, and find
out what you've got.

Yes, I would be very concerned about a hard disk failure on a volume
containing a repository. Even more reason to perform a svnadmin verify,
and then get a hotcopy of the repository on some other storage medium
(e.g., DVD or a local hard disk) asap.

Best luck!

Stuart Celarier | Corillian Corporation

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 5 15:48:18 2006

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.