On Wed, Jan 13, 2010 at 2:27 PM, Giulio Troccoli
>> From: Jon Foster [mailto:Jon.Foster_at_cabot.co.uk]
>> Sent: 13 January 2010 13:13
>> To: Andersen, Krista; users_at_subversion.apache.org
>> Cc: ssi-svn_admin
>> Subject: RE: sync bug -> corrupted proxy repo
>> Andersen, Krista [mailto:Krista.Andersen_at_itg.com] wrote:
>> > Twice I have seen one of my proxy repositories become
>> corrupted due to
>> > an apparent bug in the svnsync sync process. Has anyone else seen
>> > this type of behavior from Subversion?
>> This is probably caused by issue 3546 . This is a race
>> condition - if you have several sync processes running at the
>> same time then the mirror can get corrupted. You had three
>> commits which were 1 second apart, so your hook script
>> started 3 copies of svnsync within 2 seconds. I think this
>> is the first practical report of this bug; previous
>> discussion was theoretical.
>> > Here is a comparison the output of the svn log -v for the offending
>> > revisions (324,325) on both the corrupted and non-corrupted proxy
>> > repo.
>> It looks like rev 323 got mirrored twice (as mirror revs 323
>> and 324), then rev 324 was mirrored (as mirror rev 325).
>> > I am a bit concerned about the stability of Subversion
>> since this is
>> > the second time in two months that I have had to fix this issue.
>> > Is there a patch or something to prevent this in the future?
>> Suggested workaround: Change your hook scripts to use the
>> lockf or lockfile tools to ensure that only one instance
>> of svnsync runs at once.
> Is it not the case that a svn commit cannot start before the post-commit hooks has finished? I am asking becuase I will be implementing a DR system using svnsync, but I am not planning to let the post-commit finish before svnsync has finished (I don't care if it takes a bit longer, I can cope with that and with my users).
No, that's definitely not the case. Both pre-commit and post-commit
hooks can run simultaneously for multiple commits in parallel.
Otherwise, a pre/post-commit hook could end up being a big bottleneck.
As a practical example: if your pre-commit hook does validation of
properties (e.g. making sure svn:eol-style is set correctly on the
right types of files), then for a commit with a lot of files it may be
running for multiple seconds (even minutes). In the meantime, other
commits can be made without problems, without being bothered by that
one commit which takes a long time to pass through pre-commit hook. I
saw this in action myself with such a pre-commit hook, after I added
some debug logging at the start and the end of the hook.
Received on 2010-01-14 16:07:24 CET