NestedContinuousIntegration (a term I just made up) occurs when you are practicing ContinuousIntegration and as you are making a change (let's call it Change A) that you had hoped to integrate next, you discover that this change can be viewed as dependant upon a smaller increment of change (say Change B) that is worthy of its own independant integration.  

So, you set aside your current effort on Change A for a while, and work on the smaller increment of change as a separate isolated change using an isoloated development environment that doesn't see the Change A's partial work.  This may only take a few minutes or an hour or two.  After this is complete, you integrate it, and then you are able to use those changes in your work on Change A.

The mechanics of this can be interesting.  If Change A and Change B are not sufficiently de-coupled, you may have source file overlap (i.e. Change A already has some edits made to foo.java, and now change B needs to make edits to the same file.)  

Depending upon your development environment, and your ability to instantiate a separate, isolated development environment that doesn't "see" the other environments pending changes,  this approach may work out great.  

If you are pairing, you may just leave one person's workstation, and start using the other person's workstation.

Using PerforceVersionControl, I have been able to do this very easily on a single workstation, using multiple "clients" (a Perforce term)  After submitting the the nested change, I refresh my other environment and resolve/merge the changes into the other change.  

In fact, I currently have two changes on hold, while I'm working on a third, and all three have some common files involved.   

Is this approach a good idea?   I think that it is, as it has been working for me, but I'm curious if others have done this as well?   -- JohnVriezen

----

CategoryRefactoring, CategoryExtremeProgramming