Спорадические ошибки SVN 500 с CruiseControl.NET

Я веду несколько проектов в CruiseControl.NET. Многие из них не имеют ошибок сборки и имеют успешные сборки. Все они пытаются получить самый последний код перед сборкой.

Я заметил, что они часто не строят; CruiseControl сообщает «Исключение». Исключение составляет ошибка SVN 500 (внутренняя ошибка сервера). Он срабатывает случайно, но постоянно (например, в одном проекте каждая чередующаяся сборка терпит неудачу).

Я пробовал проверить некоторые из этих спорадически неудачных проектов с теми же учетными данными, и это работает. Я знаю сборку проектов, потому что не каждая сборка терпит неудачу.

В чем может быть проблема?

Что бы это ни стоило, вот верхняя строка примерного исключения (без URL-адреса проекта SVN или учетных данных):

ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'https://some/url/trunk'
. Process command: C:\Program Files\CollabNet Subversion Client\svn.exe log https://some/url/trunk -r "{2010-12-04T09:09:19Z}:{2010-12-07T09:08:48Z}" --verbose --xml --username ******** --password ******** --non-interactive --no-auth-cache

Изменить : Иногда кажется, что это связано с конфликтом SVN в локальной папке. Но это непоследовательно.

Награда : Я добавил награду за общее решение этой проблемы: как можно CC. NET должна быть настроена так, чтобы корректно справляться с ошибками SVN, то есть не обрабатывать сбои SVN, вызванные периодической проверкой обновлений (в отличие от запланированных ежедневных сборок), как сбои сборки, а вместо этого аккуратно отключайтесь, пока она не будет исправлена ​​или пока соединение не восстановится.

Мне самому не удалось в этом разобраться, хотя я не эксперт по CC.NET и давно не искал. Есть ли для этого поддержка или потребуется кодирование? Спасибо!

Уточняю:

• У нас есть сервер CC.NET, который нужно настроить для проверки новых коммитов и проверки + сборки + тестирования всех изменений, а затем сообщить результат.
• Если, однако, сервер SVN сработает или если мы потеряем соединение с ним, тогда он будет рассматривать это так, как будто последний коммит сломал сборку: он устанавливает статус сборки на красный и отправляет электронное письмо последнему коммиттеру, как если бы это была их ошибка.
• Да, это было бы проблемой для ежедневной сборки, но для непрерывной интеграции с каждой фиксацией я не думаю, что это полезно.