our build environment with hudson consists of 4 build processors which are equally equipped. the projects we integrated are java maven projects from a CVS repository and have these certain configurations:

• the projects are triggered when a SCM request returns a change (time plan is every 15 minutes)
• the projects are not bind to any node (build processor)

we could track the following behaviour with several projects and over the duration of more than 6 weeks now:

• when a project gets integrated first on hudson it will be checkout on one of the build processor nodes (randomly)
• when a checkin occurs on that project afterwards
  • the SCM request returns a change and triggers a build on one build processor node
  • after 15 minutes another build is triggered on the second build processor node
  • after 15 minutes another build is triggered on the third build processor node
  • after 15 minutes another build is triggered on the fourth build processor node
• when the first SCM request returns a change this change will be written to the changelog and on the project i can see: "Build wurde durch eine SCM-Änderung ausgelöst." (Build was triggered by a SCM change)
• the following three builds on the other build processor nodes also show the same trigger message but no changelog

conclusion:
every checkin on a project leads to 4 builds, polluting every build processor -> that is wrong in my opinion. just imagine what happens if there are downstream projects to that project.
hudson should keep cvs information on a central location and make SCM request from that location. it is wrong to let hudson choose a build processor on which the SCM request will be done.