(Everything said here about CVS support probably applies equally well to SVN
support, and perhaps other systems.)

If you select "Use Update" for CVS support, Hudson warns you that unversioned
files from previous builds are not cleaned from the workspace.

Generally, incremental builds are a necessity for continuous integration on
large projects for which a clean build can take an hour or more. But it is very
hard to make incremental builds "perfect", i.e. to eliminate all cases where
they would produce a different result from a clean build. Occasionally an
incremental build produces problematic build artifacts (e.g. a product with
obsolete JARs) or even fails where a clean build would not (e.g. due to
extraneous files confusing tests).

I suggest some new options to be enabled when you select Use Update. They would
all control a "CVS-clean" operation which would delete only unversioned files
from the workspace. (This is an operation which is easy to implement efficiently
using a recursive tree traversal which reads CVS/Entries; very similar to what
Hudson already does for saving a snapshot of sources.) The operation would take
place early in the build cycle, prior to running CVS update.

1. Clean unversioned files before every build. (This may be faster than deleting
the entire workspace and doing a fresh checkout.)

2. (exclusive with #1) Clean unversioned files on a schedule. Let the user enter
a time period, probably measured in days, default 1 day. Clean unversioned files
before the first build of a new period. Formally, define

period(build) = floor(timestamp(build) * days / 1000 / 60 / 60 / 24)

If n > 1 && period(build[n]) > period(build[n-1]) then do the cleaning.

3. (may be combined with #2, but exclusive with #1) Clean unversioned files
after a failed incremental build. More precisely, if the previous build failed
and no clean operation was performed before that build, then clean before this
build. This option ensures that if some leftover junk is making builds fail that
Hudson will correct itself.

3a. (option when #3 is selected) Schedule a new (clean) build upon failure of an
incremental build. This option makes Hudson correct itself eagerly, not waiting
for further commits or other triggers.

For some projects I maintain, we do the equivalent of #3a by writing a shell
command to try the build incrementally, and if it fails, clean up and restart
it. This works but has the unpleasant effect of making build failures due to
real source code errors (i.e. the usual case) take twice as long to be reported,
making it less likely that developers will correct the problem before they go home.