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

Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 30 Jun 2011 18:43:54 +0100

kmradke_at_rockwellcollins.com writes:

>> - since 1.6, if FSFS rep-sharing is not disabled there is the problem
>> of copying the rep-sharing SQLite database.
> rep-cache.db? I thought that could be easily regenerated. Is there
> another .db file I missed?

Yes, rep-cache.db. I'm not sure there is a tool to regenerate it, but
if you know it is corrupt you can simply delete the file and rep-caching
will then index any new revisions. The problem is that if it is simply
copied while an SQLite write was in progress you don't know whether or
not it is corrupt.

You also need to ensure it is copied before the rev files so that
rep-cache.db does not refer to revisions not yet in the database (recent
1.6 return SVN_ERR_FS_CORRUPT, older 1.6 could lose data).

>> > On a similar note, could a server or application crash now leave
>> > a 1.7 repository in an inconsistent and unrecoverable state?
>> Not sure what you are thinking of here, but it's perfectly OK to
>> interrupt SQLite in the middle of a transaction.
> Understood, but I want to make sure that a corrupted SQLite db
> doesn't make the whole past history of the repository unusable.
> For example, if the server dies a horrible death in the middle
> of updating r100, I'd really hope it can't easily make r1-r99
> unusable in the process.

Why do you think that would happen? How are you corrupting the SQLite

Received on 2011-06-30 19:44:37 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.