Re: same ol' repository bug

Ben Collins-Sussman <sussman@collab.net> writes:

> The repository is available here:
>
> http://www.ping.uio.no/~mortehu/empty-space.tar.gz

That repository contains a set of logfiles. If I use those to run
catastrophic recovery I get a repository which appears to have 143
revisions, but it cannot be dumped or verified

   $ cp -a empty-space empty-space2
   $ rm empty-space2/db/[_cnrstu]*
   $ db4.1_recover -c -h empty-space2/db/
   $ svnadmin dump empty-space2/ > /dev/null
   * Dumped revision 0.
   ../svn/subversion/libsvn_fs/err.c:99: (apr_err=160014)
   svn: Filesystem has no such node-rev-id
   svn: reference to non-existent node '(null).0.1' in filesystem 'empty-space2/db'
   Aborted

It may be a coincidence but that '(null).0.1' error is one I've
encountered while stress testing, see

   http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=295304

Although I can't dump the repository I can checkout a HEAD working
copy over ra_local, i.e.

   $ svn co file://`pwd`/empty-space2 wc

appears to work, as does 'svn up -rN wc'. I don't know if the working
copy is correct, but it looks plausible. Unlike ra_local, an ra_dav
checkout fails with mod_dav_svn recording a non-existent node error,
trying other revisions causes the ra_dav checkout to fail on a
different file.

Not everything works over ra_local, for example this fails

   $ svn diff -r117:118 file://`pwd`/empty-space2

although oddly enough I can update the working copy from revision 117
to revision 118.

Don't know if any of this helps!

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