I have run into the same "first" sync issue again today. This time it was on a commit that involved over 8000 paths. When I gave the sync command myself I got this error output: Transmitting file data .........<truncated - this really ran for over 6000 polka-dots>............svnsync: REPORT of 'http://serverName/parentDirectory/repoName': Could not read response body: connection was closed by server (http://serverName)
However, today my dump>load>sync method of recovery was successful. I did not see my "second" sync issue involving 'fail to get lock' today. Is there a commit size limitation on syncs? Maybe a best-practice I can warn our SVN users about? > Note that running svnsync from the post-commit hook without additional > external locking provisions is a bad idea because of the known race > condition. A huge commit can cause a sync to last long, and commits happening > while that sync is in progress will be piling up further sync jobs, > triggering a "thundering herd" effect after the long sync finishes (or > aborts). A bunch of svnsync processes might try to lock the repository > concurrently, possibly triggering the race condition which causes svnsync > meta data to be out-of-sync with the slave repository's state. Does the race condition have more than one way of expressing itself? Because it has always appeared the same when I find it. Two commits get out of order and this causes svnsync to quit. The rev-prop data is not synced on the two corrupted revs, and this causes any attempt to sync again to return with an error message asking if anyone has committed directly to the mirror. After I remove the corrupt /revs and /revprops files - and edit a couple of the /db files, the sync operation can run again. This race condition is rare - the fix is a little tricky - but quick enough to be tolerable. Is there any corruption possible from the race condition that I am not yet aware of? > I'd recommend to make your hook scripts use a common lockfile to avoid this > situation. When I looked at this method before - it seemed undesirable for some reason I don't recall. I will look into it again. > You could also run a cronjob (using the same lockfile) which tries to sync > outstanding commits in case syncs triggered by the post-commit hook were > starved during the sync of a large commit. Unfortunately, running sync from a cronjob is not an acceptable option here. Thanks, Krista -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This message is for the named person's use only. This communication is for informational purposes only and has been obtained from sources believed to be reliable, but it is not necessarily complete and its accuracy cannot be guaranteed. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Moreover, this material should not be construed to contain any recommendation regarding, or opinion concerning, any security. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Securities products and services provided to Canadian investors are offered by ITG Canada Corp. (member CIPF and IIROC - Investment Industry Regulatory Organization of Canada), an affiliate of Investment Technology Group, Inc. ITG Inc. and/or its affiliates reserves the right to monitor and archive all electronic communications through its network. ITG Inc. Member FINRA, SIPC -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
