[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
>> the repository, and delete the __db.* files from the db directory. You
>> even need to run 'svnadmin recover' - the db environment will be
>> on the next access to the db.
>> I haven't tried this to move a repository between different OSes, but I
>> 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
Or use db_recover, which leaves the environment removed after the recovery.


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.