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
Received on Thu Aug 18 12:47:55 2005