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

Re: svnadmin load leaves repos in inconsistent state

From: Michael Kefeder <ml_at_weird-birds.org>
Date: 2003-07-01 20:22:39 CEST

--On Dienstag, 01. Juli 2003 11:27 -0500 "kfogel@collab.net"
<kfogel@collab.net> wrote:

> Michael Kefeder <ml@weird-birds.org> writes:
>> I reproduced that on all 4 repositories i migrated. What i found
>> strange was that _listing_ the repositories content can crash it.
> Well, that's not more strange than any other action causing this --
> listing still requires Berkeley access, and even a Berkeley
> transaction (though not a Subversion txn).
>> I found no issue about that on your issuetracking page, i think this a
>> bug - unless somebody here has a good idea what i could have done
>> wrong, or what i can try to work around that problem. My repositories
>> work now, but just dumping/loading them was not enough.
> Oh, this is definitely a bug, but the question is, how can we
> reproduce it? I 'svn ls' repositories all the time, no problem.
> Not sure what to suggest, except possibly posting a transcript of all
> the commands you ran from start to end (including even side stuff like
> shutting down Apache before recovery), maybe someone can spot a
> misstep.

I had an old redhat 7.3 box running with subversion 0.23.x (self-compiled
from trunk) and BDB 4.1. what i did was dumping the existing repositories

svnuser $ svnadmin dump /path/to/repos > repos.svn.dump

then on a separate box where i setup gentoo 1.4rc4 using subversion 0.24.1
from ebuild i did

svnuser $ svnadmin create /path/to/repos
svnuser $ cat repos.svn.dump | svnadmin load /path/to/repos

and then (after reading the svn-book) i also tried

svnuser $ svnadmin create /path/to/repos
svnuser $ svnadmin load /path/to/repos < repos.svn.dump

to see if 'cat' could have been the problem.
Apache was not running when i did any of those steps.
then i started apache, and i called the repositories url in the browser -
after reloading the file list the error came up.

After i wrote this email i tried to reproduce the error again by recreating
the "test" repository from its dump file (it exists to let developers try
seldom used features like branching, attribs,... before they mess with the
real repos, so there's a lot crazy stuff in it). It worked now w/o problem,
the only thing that changed from yesterday is that i added mod_php support
to apache.
Yesterday i did that procedure many times with all repositories and it
always failed - seems like the bug has vanished somehow and only existed on
my machine ;) I have no idea what it was. When i find enough time i will
kill the redhat box and setup gentoo there and redo my gentoo setup steps.

conclusion: bug does no longer appear, i have no idea what happened,
subversion is running w/o problems and i should better not share my
problems unless the repositories are really f_cked and i cannot repair them


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 1 20:27:30 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.