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

Re: [PATCH] Issue #1074: Need a svnadmin command to verify that the repository is not corrupted (Take 2)

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-08-04 12:25:09 CEST

On Monday 04 August 2003 02:59, cmpilato@collab.net wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > My e-mail client was definitely messing up the patch. This should work
> > better.
>
> Oh yeah. That applied cleanly. And for what it's worth, "well done"
> to you.

Thanks! And thanks for being patient with all of the nits. :-) I'm still
trying to get used to svn's style... and modifying my editor so that I don't
have to think about it as much. :-)

> But now (and here is where you can start hating me for not thinking of
> this earlier) I have a fear about the algorith. Well, not the
> algorithm -- it's the fact that this command will be reading the
> entire 'representations' table, and all the strings dangling off those
> representations, in a single Berkeley DB transaction. On any
> decently-sized repository, I have a feeling this operation will fail
> to complete, instead dying due to a lack of available locks.
>
> How big a dataset have you been testing this patch on? My fears may
> turn out to be irrational, but something nagging at the back of my
> mind warns me of otherwise.

I took my copy of subversion and imported it into a repository. Not much of a
dataset since it doesn't have multiple revisions, and nothing else is going
on while I'm verifying the repo (not that concurrency should be an issue).

Any recommendations? I can't say that I'm very familiar with Berkeley's
methodology, so I'm at a loss for any sort of suggestion, other than to say
that 'svnadmin dump' seems to work okay. :-) What does that code path do
differently than this technique (it calls svn_repos_dir_delta() to iterate
over the contents)? I've never seen an instance where it fails.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 4 12:24:28 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.