[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: repository on client is newer than on server as a result of server hd failure

From: Ryan Schmidt <subversion-2006Q1_at_ryandesign.com>
Date: 2006-02-09 00:11:30 CET

On Feb 8, 2006, at 23:48, Josh Kuo wrote:

>> And what happens if two users commit changes one right after one the
>> other? I'd expect the two dump processes together to clobber the
>> dumpfile. Doesn't sound like such a great strategy, unless you've
>> built in some mechanism that you're not showing that ensures only one
>> dump process runs at a time.
> Yes, the script shown is an overly simplified version of what I
> did. In
> actuality, I am dumping to a temp file (name by time stamp), and once
> the dump is finished, then I copy the temp file to its final
> destination
> and rename it to the proper name (project.svnduimp or something).
> Of course, this puts a dent on the overall performance, especially
> when
> you have many commits back to back for the same repository, but it
> works
> well for me. I have a repository that does not get as many commits
> (maybe a dozen a day), but it is crucial that I do not lose any
> revisions. So I am willing to sacrifice a little performance for
> that.
> Actually, this works pretty well for me so far, the backup is
> completely
> transparent to the users, they do not see any delay when comitting.
> Thank you for pointing that out :-)

And thank you for telling me more. That sounds awful to me from a
performance perspective :-) our repository is over 1GB now and I
wouldn't want our server having to push all that data around after
each commit but it does sound like you shouldn't lose any data.

I'm thinking a quicker process would be to have the post-commit hook
only trigger an incremental backup, to a file whose name is based on
the revision number, stored in a directory "incremental". Then do a
nightly full dump, when the server is less busy, by getting the HEAD
revision (svnlook youngest); dumping everything up to that revision
into a file whose name is based on that revision, stored in a
directory "full"; deleting the now-superfluous incrementals up to
that revision; and deleting the older full dumps, possibly leaving
the last couple as additional safeguards.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 9 00:13:16 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.