>>>>> "spz" == S P Zeidler <spz%serpens.de@localhost> writes: spz> We just about manage three builds a day on TNF hardware at spz> present. We tend to have a bit more than three commits per spz> day. (On a good day, by a factor of 20). with something like git, you could fork a shadow-repository per developer at commit time. Developer pushes from his local repository to this shadow, and the build script pushes from shadow to the main repository only after the build succeeds. If the developer pushes another commit after his test-build has already been scheduled onto a CPU but before it finishes, it's his choice if he wants to abandon the current build-test and immediately start from the beginning, or push to a new repository that won't be granted a CPU until his current build batch finishes. Quite a few tools with no volunteer to write them are missing, but I don't see that ``gate commits by compile/regress testing'' is so fundamentally unreasonable regardless of project size. spz> Developers with commit access are supposed to compile-test and spz> test -before- commit. so you agree it's reasonable, but think it's only reasonable if it's done manually. It's the same amount of work happening, though, just a question of whether it's automatic or not, and whether it occurs in a data center on fast bare metal with a clever batch scheduler vs inside some ad-hoc VM on Mac OS X at 4200rpm and battery power.
Attachment:
pgpUw8IFSQ9D6.pgp
Description: PGP signature