Dirk Schenkewitz wrote:
>> Say you restored up to r100 from the backups. All the working copies
>> after r100 are doomed. If you have three working copies pointing at
>> r120, r140 and r160, you should first collect them from the users,
>> then restore them with the trick you suggested (checkout, copy all
>> the files over, commit) *and* adding padding (blank) commits into
>> the repository so that r120 in the server actually matches the
>> text-base version of the r120 repository, and so on for all three of
>> them. Now think if you 500 working copies around.
>
> Right - without padding/"empty" versions, r120 becomes r101, r140
> becomes r102 and so on. But since the intermediate versions are lost
> anyway, why not live with the new revision numbers?
Because the working copies contains the original version number! The working
copy that points at r120 expects that r120 on the server reflects *its*
text-base version. If I commit what-used-to-be r140 as r101 and so on, the
new r120 will be totally different from what the old working copy was
expecting. When the user runs update, the client will tell the server "hey
I'm revision r120, send me deltas", and the server will send deltas between
the *new* r120 and HEAD! The client will then try to apply those deltas to
*its* r120, and that won't simply work out. And what's worse, as I said
below, is that this will probably result in some weird error client-side,
which the user won't understand.
>> The net result is that now I have a post-commit hook which dumps and
>> backups a revision as soon as it is committed. I believe that any
>> other backup strategy for a SVN server (say, hotcopy once a day)
>> is basically useless.
>
> I have something similar, a script that runs as cron-job every 10
> minutes and checks if something changed, if yes, it makes a hotcopy.
I believe that there *ought* be a way to hot-rsync a Subversion server. I
didn't investigate what hotcopy exactly does, but maybe it can be repdoced
with a simple script which runs rsync instead of copy. That would save some
performance and allow it to be done after each commit even on very busy
servers.
> Every 30 minutes the backup server logs in and copies the new
> hotcopies. But if worse comes to worst, that may be not enough. I had
> some difficulties with running scripts from a hook but maybe I should
> try again, harder.
Yes. Every working copy pointing to a revision newer than the last backed up
is doomed. And there's no way that SVN can tell that user "this working copy
is now invalid, re-checkout", without invalidating *all* of them (even those
that would be valid, thanks to the backup).
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 10 14:05:07 2006