svnadmin load leaves repos in inconsistent state

[Michael Kefeder <ml...@weird-birds.org>]

Hi

I recently downgraded from berkeley db4.1 to the suggested db version 4.0. 
The only way i found to migrate my existing repos to the subversion server 
was to dump the repositories and load them back into the new subversion.
Dumping and loading was working w/o errors, when i listed the root 
directory of a repos the first time it was shown normally, but when i 
relisted the same repos a second time the db_runrecovery error came up. I 
was not able to recover the repository after that, i had to load from dump 
again. Right after loading I ran 'svnadmin recover' on it and tried listing 
again (and again, and again ;-)) - the repository is now working as 
expected. Running 'svnadmin recover' after the first 'svn ls' works too - 
but it fails after I listed the repos a second time.

example output of 'svnadmin recover' after loading - there seems to be no 
error

# sudo -u apache svnadmin recover test
Acquiring exclusive lock on repository db.
Recovery is running, please stand by...
Recovery completed.
The latest repos revision is 7.

I reproduced that on all 4 repositories i migrated. What i found strange 
was that _listing_ the repositories content can crash it.

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.
Yours
 Mike

p.s.: i'm not subscribed to the list, please add me to CC when answering.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin load leaves repos in inconsistent state

[kf...@collab.net]

Michael Kefeder <ml...@weird-birds.org> writes:
> 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 ;-)

:-) No problem, glad it resolved itself.  (Next step would have been
to upgrade to HEAD of Subversion and try again.)

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin load leaves repos in inconsistent state

[Michael Kefeder <ml...@weird-birds.org>]

--On Dienstag, 01. Juli 2003 11:27 -0500 "kfogel@collab.net" 
<kf...@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 
using

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 
;-)

Yours
 Mike



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin load leaves repos in inconsistent state

[Greg Stein <gs...@lyra.org>]

On Tue, Jul 01, 2003 at 01:20:36PM -0400, Garrett Rooney wrote:
> kfogel@collab.net wrote:
> >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.
> 
> One thing that occured to me.  You mentioned that you were migrating to 
> a new version of Berkeley DB.  Are you sure that the versions of svn and 
> svnadmin you're using are linked with the correct versions?  Perhaps the 
> outout off "ldd svn" and "ldd svnadmin" would be useful.

That sounds exactly like the problem. Mixing up BDB versions can definitely
cause problems with the database. The libraries and executables all need to
point to the "right" version of BDB.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin load leaves repos in inconsistent state

[Garrett Rooney <ro...@electricjellyfish.net>]

kfogel@collab.net wrote:

> 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.

One thing that occured to me.  You mentioned that you were migrating to 
a new version of Berkeley DB.  Are you sure that the versions of svn and 
svnadmin you're using are linked with the correct versions?  Perhaps the 
outout off "ldd svn" and "ldd svnadmin" would be useful.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin load leaves repos in inconsistent state

[kf...@collab.net]

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.

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org