2011/9/19 Thorsten Schöning <tschoening_at_am-soft.de>:
> Guten Tag David Hopkins,
> am Montag, 19. September 2011 um 04:06 schrieben Sie:
>
>> At the moment it looks like the "nuclear option" is to check out the
>> current version of everything and start a new repository with it.
>
> You can dump the old repository until the last working rev and start
> from that with your current working copies, so not loosing all of your
> history.
You *CAN*. You can also do that to a system without broken revisions.
You have to be very careful not to insert a more subtlely corrupted
revision, and you *should* change your uuid and check out new working
copies lest someone with the old revision in an old working copy wind
up severely horking themselves. Simply leaving out the broken
revision, renumbering, and keeping the old uuid will break things
very, very badly. (Did that once editing out a DVD image that someone
added, fortunately it was early in the project before the repository
was considered production grade.
>> But if I can purge the broken-ness
>> from the repo and keep the rest of the history, that would obviously be
>> better.
>
> My impression on problems like yours, which I had too, is, that in
> most cases trying to repair broken rev files was simply not
> successful. Learn from it and take the time to design a proper
> backup/sync mechanism.
This is not as easy as it sounds. Any revision in a core repository
that is corrupted online and for which rsync overwrites the backup
server's copy is a real problem, and keeping numerous old copies lying
around on tape or separate disks is a support issue. And "rsync" based
backups have real problems with revisions in the process of being
committed on the primary server. The bulky and lengthy svnadmin "dump"
and "load" processes are resource intensive and awkward to manage, and
they take a *long* time on a big repository, leaving a significant
window of opportunity for corruption.
The revisions are also vulnerable to filesystem operations by the SVN
administrator account, or shared account, on the SVN server. This is
one of the reasons I *loathe* shared write permissions for file://
access, it's vulnerable to mistakes. . A backup system that merely
replicates those without reliable off-line or distinct disk space
storage is vulnerable to all sorts of surprises. My personal favorite
solution is a NetApp storage server with filesystem ".snapshot"
directories, and an off-site backup with svnsync running in case the
NetApp goes toes-up.
Received on 2011-09-19 14:24:11 CEST