Rafał Hajdacki wrote:
> Max Bowsher wrote:
>
>> Rafał Hajdacki wrote:
>>
>>> So I will have to use repo dumping.
>>
>>
>> No, you won't.
>>
>> C. Michael Pilato said:
>>
>>> I'm not sure if anyone has experimented with deleting the __db.* files
>>> from /path/to/repos/db, and then running 'svnadmin recover' on the
>>> repository. I suppose this could solve the problem for you (unless
>>> the log.* files -- which you most certainly don't want to delete --
>>> also have platform-specific formats).
>>
>>
>> The log.* file format depends only on byte-order - so this won't be a
>> problem.
>>
>> All you have to do is make *absolutely sure* that no processes are
accessing
>> the repository, and delete the __db.* files from the db directory. You
don't
>> even need to run 'svnadmin recover' - the db environment will be
recreated
>> on the next access to the db.
>>
>> I haven't tried this to move a repository between different OSes, but I
have
>> done it when I was experimenting with temporarily deactivating the bdb
>> txn/log/lock subsystems to boost the speed of svnadmin load.
>>
>> Max.
>
> But how safe this is?
"It seems to work." People have been removing the regions from RPM databases
to clear stale locks for years now.
If you want a less hackish way, write a small C program that calls
DB_ENV->remove.
Or use db_recover, which leaves the environment removed after the recovery.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 15 21:01:42 2004