On Dec 13, 2007, at 17:47, Srilakshmanan, Lakshman wrote:
>> Ryan Schmidt wrote:
>>
>>> But... but... but... only one commit can happen at a time. And the
>>> commit is not over until the post-commit script has finished
>>> running.
>>> Therefore, if you run svnsync in the post-commit hook, there can
>>> already only be one svnsync process running at a time.
>>
>> Um, no. The commit is over before the post-commit has completed
>> (that's
>> why it is called post-commit). Just because it doesn't return
>> control
>> to the client until after the post-commit fires, doesn't mean someone
>> else can't commit. In fact, it has long be recommended that
>> long-running post-commit steps be forked into the background, which
>> makes the situation even more muddy...
>
> A) "svnadmin dump --incremental" or "svnsync" should be used as the
> preferred method for backing up ?
Not necessarily exclusively. But both of these are great for the post-
commit hook. You may want to employ other backups as well, for
example a full dump or hotcopy every month or on some other schedule.
> B) If the main repository is corrupted, then wouldn't the above
> strategy
> copy the corruption over to the backup ? I am assuming that is
> *not* the
> case and would appreciate if someone can fill the gap in my knowledge.
I was incomplete; I meant "svnadmin dump $REPOS --incremental -r
$REV". You're only backing up the just-committed revision. If
repository corruption has occurred, presumably this would be in prior
revisions, which aren't getting backed up again. svnsync also, as far
as I know, just transmits to the mirror the changes since the last sync.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 14 00:51:59 2007