You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Holger Krekel <py...@devel.trillke.net> on 2004/02/23 17:07:24 UTC
dump problem with 0.32.1
Hello,
first of all: congratulations for the birthday of subversion!
I took it as an opportunity to try to update one of my repositories
which still runs at 0.32.1 but alas.
when performing 'svadmin dump' after a successful 'svnadmin recover' i get:
* ..... 147 revs ....
* Dumped revision 148.
* Dumped revision 149.
* Dumped revision 150.
* Dumped revision 151.
svn: Filesystem has no such representation
svn: svn_fs__bdb_read_rep: no such representation 'emw'
This is the output of ldd `which svnadmin` on a reasonably up-to-date
gentoo-system:
linux-gate.so.1 => (0xffffd000)
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x40016000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x40029000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x4004b000)
libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40053000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x400f9000)
libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4011d000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40133000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4013a000)
libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x40161000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4018c000)
librt.so.1 => /lib/librt.so.1 (0x401dd000)
libm.so.6 => /lib/libm.so.6 (0x401f0000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40212000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40240000)
libdl.so.2 => /lib/libdl.so.2 (0x40255000)
libc.so.6 => /lib/libc.so.6 (0x40258000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
nothing else was accessing the repo at the time.
I remember that this repository was at one point successfully dumped at
0.28.0 and loaded into 0.32.1 (by the ebuild script). Other than that,
I think that only apache2 was updated recently but not e.g. the bsd db.
Apparently there once was a similar issue:
http://www.contactor.se/~dast/svn/archive-2003-08/1388.shtml
but it wasn't publically reported on afterwards.
I can provide the repository if needed. Btw, This is the first time
that i am lost with how to recover data from a repository ...
thanks,
holger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: dump problem with 0.32.1
Posted by Holger Krekel <py...@devel.trillke.net>.
To users@subversion.tigris.org wrote:
> Hello,
>
> first of all: congratulations for the birthday of subversion!
i second that :-)
> I took it as an opportunity to try to update one of my repositories
> which still runs at 0.32.1 but alas.
>
> when performing 'svadmin dump' after a successful 'svnadmin recover' i get:
>
> * ..... 147 revs ....
> * Dumped revision 148.
> * Dumped revision 149.
> * Dumped revision 150.
> * Dumped revision 151.
> svn: Filesystem has no such representation
> svn: svn_fs__bdb_read_rep: no such representation 'emw'
ok, i wasn't able to recover the problem directly but i found a copy
of the repository (just one revision older) that was ok. Actually
this older version was copied to the new location via
find oldpath -print | cpio -p newpath
and later updated with on
rsync -auxv oldpath newpath
was performed. I presume that during those copies something must
have changed (although that's hardly possible) since the repository
at 'oldpath' is still ok while the 'newpath' one is broken. Copying
it again doesn't produce the problem (of course).
so i am still looking for an answer, but in a relaxed way :-)
holger
> This is the output of ldd `which svnadmin` on a reasonably up-to-date
> gentoo-system:
>
> linux-gate.so.1 => (0xffffd000)
> libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x40016000)
> libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x40029000)
> libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x4004b000)
> libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40053000)
> libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x400f9000)
> libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4011d000)
> libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40133000)
> libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4013a000)
> libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x40161000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x4018c000)
> librt.so.1 => /lib/librt.so.1 (0x401dd000)
> libm.so.6 => /lib/libm.so.6 (0x401f0000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40212000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x40240000)
> libdl.so.2 => /lib/libdl.so.2 (0x40255000)
> libc.so.6 => /lib/libc.so.6 (0x40258000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> nothing else was accessing the repo at the time.
>
> I remember that this repository was at one point successfully dumped at
> 0.28.0 and loaded into 0.32.1 (by the ebuild script). Other than that,
> I think that only apache2 was updated recently but not e.g. the bsd db.
>
> Apparently there once was a similar issue:
>
> http://www.contactor.se/~dast/svn/archive-2003-08/1388.shtml
>
> but it wasn't publically reported on afterwards.
>
> I can provide the repository if needed. Btw, This is the first time
> that i am lost with how to recover data from a repository ...
>
> thanks,
>
> holger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org