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