Ongoing baselines

After developers start working on their streams in the new project and make changes, create baselines on the integration stream and on any feature-specific development streams on a frequent (nightly or weekly) basis. This practice has several benefits:

Developers stay in sync with each other’s work.
It is critical to good configuration management that developers have private work areas where they can work on a set of files in isolation. Yet extended periods of isolation can cause problems. Developers are unaware of each other’s work until you incorporate delivered changes into a new baseline, and they rebase their development streams.
The amount of time required to merge versions is minimized.
When developers rebase their development streams, they may need to resolve merge conflicts between files that the new baseline selects and the work in their private work areas. When you create baselines frequently, they contain fewer changes, and developers spend less time merging versions.
Integration problems are identified early.
When you create a baseline, you first build and test the project by incorporating the work delivered since the last baseline. By creating baselines frequently, you have more opportunities to discover any serious problems that a developer may introduce to the project inadvertently. By identifying a serious problem early, you can localize it and minimize the amount of work required to fix the problem.

If you are working in a single-stream project, you do not need to create baselines frequently. Developers see each other’s changes as soon as they check in files; they do not rebase to the latest recommended baselines. The primary purpose of baselines in a single-stream project is to identify major project milestones, such as the end of an iteration or a beta release.