Anyone have any thoughts on this?
On 20/08/2007, at 10:59 AM, Brett Porter wrote:
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
