Sporadic SVN 500 Errors With CruiseControl.NET

Question

I'm running several projects in CruiseControl.NET. Many of them have no build errors and have successful builds. They all try to pull the latest code prior to building.

I've noticed that they frequently fail building; CruiseControl reports "Exception." The exception is an SVN 500 error (internal server error). It strikes randomly but persistently (eg. in one project, every alternating build fails).

I've tried checking out some of these sporadically failing projects with the same credentials, and it works. I know the projects build, because not every build fails.

What could the problem be?

For what it's worth, here's the top line of an exemplary exception (without SVN project URL or credentials):

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

Edit: Sometimes this seems to be because there's an SVN conflict in the local folder. But it's not consistent.

---

Bounty: I've added a bounty for a general solution to this: how can CC.NET be configured to gracefully cope with SVN errors, i.e. do not treat SVN failures triggered by a periodic update check (as opposed to scheduled daily builds) as build failures but instead gracefully back off until it's fixed or until the connection recovers.

I haven't managed to figure this out myself, although I'm not a CC.NET expert and haven't looked for a long time. Is there support for this or would it need coding up? Thanks!

To clarify,

• We have a CC.NET server to set up to check for new commits and checkout + build + test all changes then report the result.
• If, however, the SVN server goes down or if we lose connection to it then it treats this as if the last commit broke the build: it sets the build status to red and emails the last committer as if it was their fault.
• Yes, this would be a problem for a once-a-day build job but for continuous every-commit integration I don't think this is useful behaviour.

Answer 1

One hard way of solving this problem would be to check for modifications with a batch file or a custom wrapper (instead of the source control facility of CruiseControl.NET) that calls the svn client and creates a file (or some other way of signaling changes) if the build is required. The batch or wrapper could treat the exceptions as needed. Of course, this solution might require altering the rest of the build process.