Description Steve Powell 2010-10-22 06:28:56 EDT

Currently pushed mods to repositories while a ripplor script is being executed cause the ripple to fail at the end (during the push phases) and hand-fixing can be a problem.

This enhancement suggests splitting ripplor into phases, each of which can be executed fairly safely without hurting other changes that might be happening.  This would mean that ripple's can happen while other work progresses (which may be in another time-zone!) with only a minor inconvenience TO THE 'RIPPLER'.

Phase 1:  Make all the source changes (version upgrades) to all the repositories before building them, putting the changes on a branch which is specific to the ripple being performed.  All these commits are pushed.

Phase 2: Run the builds on the specific ripple branch for all repos. This is where the specific builds are published as you go - necessary to get all dependencies to work, as we know.  If the branches were all pushed, this step can be done separately from phase 1, even automatically on a build server, if we set it up right.  The builds, though they need to be done in sequence, need not all pass, though they should all be attempted.

Phase 3: When we are happy with the builds in Phase 2, we can then merge all the ripple branches into the master branches of the repos. This can be done rapidly, and irrespective of success, WITHOUT PUSHING.  The merges that fail can be hand-fixed before pushing the merges, or the ripple can be abandoned if the merges are too complex.

The advantages here are the same advantages of multi-threading a serial algorithm -- the pitfalls and drawbacks are similar, too.  One major advantage is the reduction of the need for transaction-style locks on the code-base.