[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repo on FAT32 accesed from Windows and Linux

From: Max Bowsher <maxb_at_ukf.net>
Date: 2004-03-15 21:00:07 CET

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

This is an archived mail posted to the Subversion Users mailing list.