RE: ALARM !!! recover from database crash
Date: 2005-08-18 15:06:09 CEST
sorry I don't criticizes you
I just complain about subversion
just to provide more details:
I use subversion to autocommit changes of ~30 B2B/EAI servers around the world
Currently I have 6 days downtime and I got the answer
Mit freundlichen Grüßen
On 18.08.2005, at 09:59, Andreas Otto wrote:
>>> after a crash of our raid5 array I recover the svn database from
Is there a specific problem with my instructions, or a more general "I don't want to do it that way" / "Subversion should handle it for me"? I did take great care in writing the instructions, going so far as to reproduce the original poster's environment on my own machine before responding, and he said my instructions got him back on track, so if there's something specific that's not working about them, maybe I can help.
As to whether Subversion could handle this better, I'm not sure how.
Say the repository is at revision 2600, and you check out a working copy of it. A lot of things get stored in the working copy's .svn directories which make a note of the way this part of the repository looked at revision 2600. When you commit changes, the Subversion client transmits to the server a message that basically says "I want to commit some changes. Here are the differences between revision 2600 and the new stuff; please apply them." The repository then says "Ah yes, I know revision 2600. Your changes seem in order. The new revision number is 2605."
But if you then have to restore a backup of the repository from, say, revision 2500, now you have a problem when you try to commit that same working copy. The commit request arrives at the server, and the server has to say "Differences from revision 2600? Sorry, I've never heard of that revision, so there's nothing to which your diff could reasonably apply." The working copy doesn't contain a complete history of every change made up to revision 2600. That's not its job; that's the repository's job. All the working copy knows is how the repository looked *at* a particular revision, and if the server has forgotten how that revision looked, as in your case, then that breaks things.
Let this serve as a lesson that you should ensure that you always have very current backups of your repository. Set up a post-commit hook that dumps the just-committed revision to an incremental dump file. If you allow revprop changes, set up a post-revprop-change hook to either back up the affected revisions again or write the svn propset commands to a text file, to be executed manually in the event a database restore is necessary. Optionally, do a weekly or monthly full dump and clean out the incrementals up to that point, to keep it from getting out of hand. You can also copy (or, for BDB repositories, hot-copy) the raw repository files for another level of security.
This is an archived mail posted to the Subversion Users mailing list.