Convert Svn to Hg: svn.core.SubversionException: 180001 - Unable to connect to a repository at URL 'file:///var/lib/svn/trunk/ascii2psql'

[Ambarish Sridharanarayanan]

On Fri, 14 Dec 2012, Kevin Bullock wrote:

> On Dec 14, 2012, at 2:32 AM, Ambarish Sridharanarayanan wrote:
>
>> I'm trying to convert my local Subversion repository over to Mercurial. I'm a basic Svn user and a novice Hg user. I'm trying this on Fedora 17, running:
>>
>> * subversion-1.7.7-1.fc17.i686
>> * mercurial-2.2.3-1.fc17.i686
>> * python-2.7.3-7.2.fc17.i686
>>
>> Please see transcript below. svn list works fine. Trying to convert the repo to hg gives me an error and also seems to leave behind some stale locks, as logged by a subsequent BerkeleyDB command. Thanks for any help!
>
> [...]
>
>> svn.core.SubversionException: 180001 - Unable to connect to a repository at URL 'file:///var/lib/svn/trunk/ascii2psql'
>> 180001 - Unable to open an ra_local session to URL
>> 180001 - Unable to open repository 'file:///var/lib/svn/trunk/ascii2psql'
>> 160029 - Berkeley DB error for filesystem '/var/lib/svn/db' while opening environment:
>>
>> 160029 - DB_RUNRECOVERY: Fatal error, run database recovery
>
> Have you tried `svnadmin verify` or `svnadmin recover` on the repo?

Yes, they ran clean.

>> $ rpm -q db4
>> BDB2053 Freeing read locks for locker 0x67a: 9945/3078109760
>> BDB2053 Freeing read locks for locker 0x67b: 9945/3078109760
>> BDB2053 Freeing read locks for locker 0x67c: 9945/3078109760
>> BDB2053 Freeing read locks for locker 0x67d: 9945/3078109760
>> db4-4.8.30-10.fc17.i686
>
> These read locks are related to *RPM's* database, not Subversion's.

I thought of that, but I only see those messages right after I try "hg 
convert", I see them everytime I run "hg convert", and I see them if I run 
a svn command as well; so I was wondering if there's some sort of global 
state BerkeleyDB maintains. Anyway, this may not be directly relevant.

> Have you checked the integrity of your disk lately?

Good idea! I ran fsck on the relevant partition - ran clean. This is a VM 
running inside VirtualBox/Windows, so I also ran Windows' filesystem check 
- clean. Also, "svn ls" seems to run clean, so I'm not convinced there's 
fs-corruption.

Any other thoughts?

Thanks!
Ambarish