Sporadic SVN 500 errors with CruiseControl.NET

Question

I am running several projects in CruiseControl.NET. Many of them have no build errors and have successful builds. They all try to pull out the latest code before it is built.

I noticed that they often fail; CruiseControl reports an Exception. An exception is the SVN 500 error (internal server error). It hits randomly, but persistently (for example, in one project, each build variable does not work).

I tried to check out some of these sporadically unsuccessful projects with the same credentials, and it works. I know that projects are being built because not every assembly works.

What is the problem?

For what it's worth, the top line is a sample exception (without the 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 happens because there is an SVN conflict in the local folder. But this is not consistent.

---

Bounty : I added generosity to the general solution: how can I configure CC.NET to gracefully handle SVN errors, that is, not to handle SVN failures caused by periodic updates, check (as opposed to scheduled daily builds) as build failures, and instead gracefully back off until you lock or until the connection is restored.

I could not understand this, although I am not a CC.NET expert and have not been looking for a long time. Is there any support for this, or does he need coding? Thanks!

To clarify,

• We have a CC.NET server to configure new commits and checkout + build + to check all changes, and then report the result.
• If, however, the SVN server is not working, or if we lose connection with it, then it considers it as if the last fixer broke the assembly: it sets the status of the assembly in red and sends the last committer, as if it were their error.
• Yes, this will be a problem for one-time creation work, but for continuous integration with each latch, I don't think this is a useful behavior.

Answer 1

One of the difficult ways to solve this problem is to check for changes using a batch file or a custom shell (instead of the version control tool CruiseControl.NET), which calls the svn client and creates a file (or in some other way) of signaling changes) if assembly is required. A package or wrapper can handle exceptions as needed. Of course, this decision may require a change in the rest of the assembly process.