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

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
db?

-- 
Philip