[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 17:53:54 +0100

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:

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

Received on 2011-06-30 18:54:30 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.