Mainline Chaos
Before describing best practices for global teams, first take a look at some common problems. If everybody in development is making changes against the mainline, introducing a bad change affects everybody until it is detected and corrected. Waiting for someone to fix a change that is impacting everybody is bad enough when the change was committed locally, but it becomes severe when the committer won't even be awake for another eight hours.
You may determine that getting the latest files, which included that bad change, caused you problems. If you have your own changes in progress, you may conclude that it is the combination of your changes and other people's changes that are causing the problem and temporarily solve the problem by backing out the update. However, backing out is generally harder if you have your own changes in progress.
Another way to think of the bad changes problem is that bad changes are a form of unwanted changes. Clearly, nobody wants bad changes. But not everybody wants all changes from all developers as soon as they are committed, either. Perhaps the change includes changes to the API, or perhaps you just don't want to take the time to rebuild the affected files. One way to handle this is to update just parts of your work area when you do an update. The problem with a partial update is that you run the risk of missing dependent changes.
Limiting change is especially problematic at integration and release time. The best way for a team to get their functionality stable is for nobody else to make changes to the mainline. Unfortunately, all teams want to be the only team to make changes while all other teams wait. A typical integration practice is to create a schedule and let each team take their turn integrating their changes with the mainline and stabilizing their functionality. This approach serializes the work and introduces artificial delays. It also means that the other teams have to find something else to do with their time while they wait. A common way of handling the scheduling is via token-passing. Only the team who has the token can commit changes. I've seen people use inflatable dinosaurs, traffic cones, and various other tokens. This practice may work fine for collocated teams, but it is more difficult to use an inflatable dinosaur when one of the teams is halfway across the world.
Whatever method is used, once the first round of integration has completed, it is likely that the functionality of one or more of the teams will need further adjustment, initiating yet another serialized integration round.
