I think I understand this problem more now.
the svn errors are a transient problem - it occurs before a build
takes place, but they are recorded as a built result. So when they
succeed again, no build occurs because no update has taken place.
I see two possible corrections to this problem:
1) don't record a build result for update failures (have some sort of
project level error and different way of notifying/correcting).
2) rebuild a project that was in error state before.
Only the first would also address the problem of having difficulties
diagnosing errors that occur even earlier and don't record a build
result at all. It also is a nice separation of configuration/
environmental errors vs actual build failures. It helps with the
separation of roles when you have a server admin and developers that
just commit on the code.
However, it's a lot more work, and it might be better to schedule
that for the future and fix it via (2) for 1.1.
what do others think?
- Brett
On 16/08/2007, at 1:46 PM, Brett Porter wrote:
I'm also seeing where there is a "real" error, like the SVN server
not being reachable, and it not trying to build ever again.
On 16/08/2007, at 1:40 PM, Brett Porter wrote:
I see too often project's getting stuck in "error" state, and it's
quite hard to diagnose what's wrong. They don't automatically
recover, and there is no build result for the actual error (so
clicking the icon takes you to the last successful one)
Anyone have any thoughts on how we can improve this?
- Brett
