Giovanni Bajo wrote:
> 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.
Take a look at
http://svn.collab.net/repos/svn/trunk/contrib/server-side/svn-fast-backup
It's my favorite hot backup system, assuming you have a Unix OS and an FSFS
repository. It does the fastest backups, faster than svnadmin hotcopy, since it
uses rsync's --link-dest option to hard link your latest backup to the previous
revisions backup, 99% of the files are unchanged.
It does require subprocess, which only comes with Python 2.4.
After doing the hot backup to a local filesystem using svn-fast-backup, I would
recommend doing an rsync of the directory containing the hot backups to another
box so you have the repository on more than one disk, making sure to use -H so
that rsync preserves hardlinks. Do not just rsync the new hotbackup to a new
box, as then you'll loose the hardlinks between hot backups at different revisions.
Regards,
Blair
--
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 24 20:21:29 2006