Hi,
this sounds good, -> I'll try it
Mit freundlichen Grüßen
Andreas Otto
-----Original Message-----
From: Andreas Mahel [mailto:andreas.mahel@ch.ibm.com]
Sent: Thursday, August 18, 2005 3:40 PM
To: Otto Andreas (IT OS PA external)
Cc: users@subversion.tigris.org
Subject: RE: ALARM !!! recover from database crash
Another try ;-)
If I understand correctly, your problematic working copies are production systems, so the files themselves should not be touched.
Hm.
So the main problem is that the local "pristine" copies svn keeps in its .svn directories does not resemble any valid status/revision in the repository.
Then we might want to get rid of those old/outdated cache data.
How about:
1. restore the repository from old backup (always our favourite first step) 2. check out a working copy 3. throw away everything except the .svn folders and their content 4. on each wc, remove the .svn folders, and replace by the new ones
Maybe this helps?
Best regards,
Andreas
<OttoA.External@i
nfineon.com>
To
18.08.2005 15:06 <subversion-2005@ryandesign.com>
cc
<users@subversion.tigris.org>
Subject
RE: ALARM !!! recover from
database crash
Hi,
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
(development/test/production). the data is mostly xml data.
in addition a lot of developers using this software to store their work
I have done the normal job of an administrator to do a backup every night
(I understand that a backup one second before a raid crash would be better
but I don't found an option in the raid array to send an email to me
saying "I'll fail at 10:06am please do an backup until 10:05am" :-) )
Currently I have 6 days downtime and I got the answer
"I have to remove the repository and start from beginning"
-> (this is not right in detail but it sounds to me like this)
the problem is that the xml data I cannot just do
"stop the production servers ... do some nasty changes on the file system level
(deleting, moving files around or something else)... setup a new workplace
... and restart the server"
I'm afraid that I create some nasty bugs during this operation on my
production environment
Mit freundlichen Grüßen
Andreas Otto
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2005@ryandesign.com]
Sent: Thursday, August 18, 2005 12:45 PM
To: Otto Andreas (IT OS PA external)
Cc: users@subversion.tigris.org
Subject: Re: ALARM !!! recover from database crash
On 18.08.2005, at 09:59, Andreas Otto wrote:
>>> after a crash of our raid5 array I recover the svn database from
>>> an old backup.
>>> the problem is that the old state was !not! the state of the last
>>> check-in:
>>>
>>> some examples:
>>>
>>> host:>svn update
>>> svn: Reference to non-existent revision '2544' in filesystem
>>> '/path/to/svn/repositories/db'
>>>
>>>
>>> host:>svn commit -m new
>>> Sending MqSeries.config
>>> Sending WebMethods.config
>>> Transmitting file data ..svn: Commit failed (details follow):
>>> svn: Base checksum mismatch on '/applications/OpMenu/
>>> WebMethods.config':
>>> expected: e83613d37b51b9a182dace8b33bb860b
>>> actual: 8bc484dc39ad9face27831e60e60a6a1
>>>
>>>
>>> I'm not interested to get the !latest! level working ...
>>> I'm just fine to get anything working (e.g. start to check-in the
>>> current level to the HEAD release , even if the HEAD release is old)
>>
>> An answer I gave someone else recently will probably help you:
>>
>> http://svn.haxx.se/users/archive-2005-08/0347.shtml
>
> I don't understand the answer.
> From my point of view it is a normal behavior for a SW to recover
> from
> an old backup release.
> if I read this email I get the conclusion that it is not possible
> !!!
>
> I thing it is a business-critical design-error of subversion
>
> what I want:
>
> 1. install an old backup
> 2. perhaps run a svnadmin ??? command to clean up
> 3. continue to work
>
> for me everything is perfect because I have a working old release
> including the history the old HEAD in the .svn directory of
> a checkout and the current changes in the working directory
>
> and subversion say I'm not able to recover !!!!!!!
>
> I'm not able to recover with the information below !!!!
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.
Subversion is a complicated system, and it has to be able to rely on a number of things in order to do its job. One thing it relies on is that the .svn directories aren't tampered with; another is that when when you go to check in a working copy, then the repository is still the same one that you checked out from. In your situation, you restored an old backup, so the repository is not the same one the working copy was made from.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 18 16:32:55 2005