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