Errores esporádicos de SVN 500 con CruiseControl.NET

Estoy ejecutando varios proyectos en CruiseControl.NET. Muchos de ellos no tienen errores de compilation y tienen comstackciones exitosas. Todos intentan extraer el último código antes de build.

Me he dado count de que con frecuencia fallan en la construcción; CruiseControl informa "Excepción". La exception es un error SVN 500 (error interno del server). Golpea de forma aleatoria pero persistente (por ejemplo, en un proyecto, todas las construcciones alternativas fallan).

He intentado verificar algunos de estos proyectos esporádicamente fallidos con las mismas cnetworkingenciales, y funciona. Sé que los proyectos se crean, porque no todas las construcciones fallan.

¿Cuál podría ser el problema?

Por lo que vale, esta es la línea superior de una exception ejemplar (sin URL de proyecto SVN o cnetworkingenciales):

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 

Editar: a veces parece ser porque hay un conflicto SVN en la carpeta local. Pero no es consistente.


Bounty : He añadido una recompensa por una solución general a esto: cómo se puede configurar CC.NET para lidiar con errores SVN, es decir, no tratar fallas SVN desencadenadas por una actualización periódica (en oposition a las comstackciones diarias progtwigdas) como fallas de compilation, pero en cambio retroceder con gracia hasta que se solucione o hasta que la connection se recupere.

No he logrado resolver esto por mi count, aunque no soy un experto en CC.NET y no he buscado durante mucho time. ¿Hay soporte para esto o necesitaría encoding? ¡Gracias!

Para aclarar,

  • Tenemos un server CC.NET para configurar para verificar si hay nuevos commits y checkout + build + probar todos los cambios y luego reportar el resultado.
  • Sin embargo, si el server SVN se cae o si perdemos la connection, se trata como si el último compromiso rompiera la construcción: establece el estado de la construcción en rojo y envía un correo electrónico al último confirmador como si fuera su culpa.
  • Sí, esto sería un problema para un trabajo de compilation una vez al día, pero para la continuous integration de cada compromiso. No creo que este sea un comportamiento útil.

Una forma difícil de resolver este problema sería verificar las modificaciones con un file de process por lotes o un contenedor personalizado (en lugar de la function de control de origen de CruiseControl.NET) que llama al cliente svn y crea un file (o alguna otra forma de cambios de señalización) ) si la compilation es requerida. El lote o envoltorio podría tratar las excepciones según sea necesario. Por supuesto, esta solución podría requerir la alteración del rest del process de compilation.