kmra...@rockwellcollins.com wrote on Thu, Jun 30, 2011 at 09:06:28 -0500: > Daniel Shahaf <d...@daniel.shahaf.name> wrote on 06/30/2011 07:35:36 AM: > > I'm going to say this even more clearly: > > > > If you backup a repository by copying its files while a server is > > running, the backup may be created corrupted. > > > > http://subversion.apache.org/docs/release-notes/1.7#single-db (sic) > > This does not seem point to any additional warnings about the server > side yet (only the client)... >
Read the attached issue. FSFS on 1.7 is affected --- specifically, revprops.db, which contains the only copy of revprops of packed revisions. > I realize regular backup software was never truly endorsed, but in > the past, the "corruption" could always be rolled back to the last > valid commit, since the server never modified files once they were > created. You could lose the last commit and need to manually > perform surgery on the "current" file, but the repo would still be > functional. Since backups are considered a snapshot in time this > isn't a big problem since it just moves the timeframe of the > backup to the previous commit. > > To be honest, both hotcopy and svnsync are way too slow for > any server of appreciable size. If 1.7 is designed to modify > existing files in place on the server, potentially rendering > snapshot backups non repairable, it would be a huge regression. > Per above, it is designed this way. Could you raise this issue on dev@ please? Would adding an 'svnadmin create'-time knob that says "Pack only revision shards but not revision property shards" solve your issue? > Kevin R.
