Many, many people seem to equate ContinuousIntegration with CommitEarlyAndOften.  While committing your code to the version control system is one example of integration, it's only the tail of the donkey.

Continuous Integration is making sure you don't create a mini-universe that ends up getting crushed by the real universe.

Examples of non-continuous integration:
	* "Okay, my team is going to do the client, and yours is going to do the server."
	* Creating a generic web-page parsing class... ''then'' actually trying to use it parse the data you want.
	* "It's going to take me a few days to complete this refactoring, so I'll do all my work on a branch."
	* "I'll make sure my code matches the spec before trying to integrate it into the system."
	* ...

'''However'''

In the case of using head to stuff your partial refactorings, you may find that the refactoring goes wrong part-way through.  You cannot simply roll-back the changes made, because intervening commits from other developers are likely already in the repository.  You have to 'unwind' your changes manually when this happens.  This is, for all intents and purposes, the equivalent of merging branches (in terms of workload involved).  ''[Actually, if you're using darcs, you *can* simply rollback the changes (unless someone else edited the same lines after you did).  It is still equivalent to merging.  I think the same applies to any SensibleVersionControl^W DistributedVersionControl system.]''

Some personal experience relevant to this:
* SamuelFalvo works for a company that has a one-week release cycle.  He had to pull down a new version of the software for some localized edits.  The version pulled from the repository, however, was positively broken.  There were many hours spent debugging the breakage, which included tons of undefined symbols everywhere, among other things.  It wasn't until I checked the CL history that I realized that I grabbed a version right in the middle of a refactoring.  He had to wait for the refactoring to be finished before he was unblocked.  Had the refactoring engineer used a branch, he wouldn't have been negatively impacted.

Therefore, some of us ''do'' feel that large-scale refactorings ''do'' need to be done in a branch.  It is felt that ''those doing the refactoring'' are responsible for periodically polling from the master branch to ensure that ''their'' codebase is up to date.  By doing so, you ''are'' doing continuous integration.  Then, when the branch is complete, the workload involved with merging branches is significantly reduced, ''and'' you have a consistent project head at all times.  Use of a distributed version control system, such as Git, et. al., is ''strongly'' recommended to support this development practice.

Answer: commit all refactorings in steps that work. If this means you have a changeset that touches 500 files, so be it. If your changeset takes a week to develop, so be it. In this case, I back up my delta from source control regularly. This is not the same as branching as I am still fetching daily. --JoshuaHudson
----

See also ContinuousIntegrationPatterns, ContinuousIntegrationApplied, FrequentReleases, IncrementalIntegration, HorizontalStripes, AntHill, IntegrationGuard, ContinuousIntegrationIsMoreThanVersionControl
----
CategoryConfigurationManagement