When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

Started on Aug 22, 2013 9:20:58 AM
Using locally configured password for connection to :pserver:someone@someplace:/cvshome
cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule 
...
Changes Found

This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:

Started on Aug 22, 2013 9:25:58 AM
Using locally configured password for connection to :pserver:someone@someplace:/cvshome
cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
...
Changes Found

And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log. The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)

When the second build starts building, this is how it gets its changelog

Using locally configured password for connection to :pserver:someone@someplace:/cvshome
cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 someModule 

Where 9:21:14 is the time in which the first build finished. Thus we have this "phantom build" triggered by "no changes"

Workaround: Set polling longer interval, but this comes at the cost of responsiveness.