Whole tree up to date before committing

[Nicholas Allen]

> I guess you are talking about https://launchpad.net/pqm
>
> A series of doubts arise:
>
> So let's suppose that the merge have no conflicts, the build works and
> the test suite succeeds. What's next? If the PQM automatically merges
> and commits to master, the developer is not forced to review the final
> state of the master branch, so it is not different from subversion's
> implicit merge + buildbot. 
It is different because in Subversion it lands on trunk *before* the
tests have passed. With gatekeeper (eg launchpad) it only lands *after*
they have passed and therefore the trunk can be considered more stable.
This can be a problem in subversion because a problem may not be
detected by the buildbot until many revisions after it was incorporated
into trunk.
> OTOH, if the PQM reports back to the
> developer that the patch introduces no problems, before he commits maybe
> the master trunk diverged again and so he must submit the patch to the
> PQM once more time.
>   
> If my understanding is right, there is one PQM and all patches must go
> through it. This creates a bottleneck of its own. For the project I'm
> thinking on, even a 16 way machine would be unable to keep pace with the
> patches at peak hours, and that would check just one platform.
>   
It creates no more of a bottleneck than having to run each revision
through the buildbots (which is what you claim you currently do, if I
understood correctly). So if this is the case the only change would be
that trunk guaranteed buildbot success for every revision whereas in
your current subversion setup it does not. That has to be better doesn't it?

Nick