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

kmradke_at_rockwellcollins.com writes:

> I know using traditional server backup software has never been
> recommended on fsfs repositories. However, since the server
> never rewrote any files after the transaction was finalized, the
> only previous issues with using a snapshot based backup mechanism
> would be that the current file was out of sync with reality. This
> could be easily fixed, by manually modifying the current file
> to reference the previous revision number if needed.

There are problems simply copying a live repository:

 - since 1.6, if FSFS rep-sharing is not disabled there is the problem
   of copying the rep-sharing SQLite database.

 - since 1.2, if Subversion file locking is not disabled there is the
   problem of copying the locks directory:
   http://subversion.tigris.org/issues/show_bug.cgi?id=3750

> Daniel mentioned this is no longer the case since revprop packing
> using a sqlite database is not guaranteed to be consistent
> while it is open.

Not sure what you mean. The restriction is that it is not valid to
simply copy an SQLite database file while it being written.

> In my opinion this is a huge regression from
> previous functionality. Using hotcopy or svnsync is not practical
> for larger environments.

I suppose incremental hotcopy might help if it were implemented:
http://subversion.tigris.org/issues/show_bug.cgi?id=3815
We would have to fix 3750 first.

> 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.

-- 
Philip