Whole tree up to date before committing

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Óscar Fuentes wrote:
...

> The model you propose is more of a bottleneck because changes must be
> checked sequentially by a single PQM (unless you implement something
> like "speculative testing", where a machine assumes that patch N
> succeeds, starts testing patch N+1 and commits after the machine that
> was testing patch N finishes). A PQM that tests one patch at a time is
> not fast enough for that project, even if it is comprised of several
> machines each testing one platform in parallel.

You can still go by N via a tree pattern. You just create separate
'integration' branches, where each integration branch tests and merges a
patch, and then those integration branches get merged into the 'trunk'
branch. Think of it as 'worker-queues' for integration.

It does add extra 'merges' into the system. However, it does let you
scale into many PQM machines. Also, by offloading the 'run the full test
suite' into the automated machines, it reduces the *developer's* need to
run the full test suite before committing.

> 
> With subversion's model it is trivial to have a machine testing revision
> N, other testing revision N+1, etc. so it is just a matter of adding
> more machines as the project grows. When a problem is detected removing
> it is not as simple as dismissing a patch, but as this rarely happens,
> it is not a big issue.
> 
> I repeat that bzr policy is the right one, but it cannot be applied to
> some projects, so subversion's model is a reasonable trade-off.
> 

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrg4m8ACgkQJdeBCYSNAAMmWACfek7wUH/jGcf+ugmdzrtRE22+
JOcAoJ3MY3PIhCL9oi9fXC+FxaYd/uMg
=5wqq
-----END PGP SIGNATURE-----