Normally each team-member does all of their work in their own individual workbench, isolated from others. Eventually they will want to share their work with others, and get their team-mates changes. They do this via streams.
Streams are the place where a team shares and integrates their ongoing work.
A stream can be thought of as a shared workspace that is updated by team members as they make changes to the project. This model allows individuals to work on a team project, share their work with others as changes are made, and access the work of others as the project evolves.
As team members produce new work, they share this work by releasing those changes to the stream. Similarly, when they wish to get the latest available work, they catch up to the changes on the stream. Thus the stream is constantly changing, moving forward as team members submit new work.
The stream effectively represents the current state of the project. At any point a team member can catch up to the stream and know they are up to date.
Team Programming Model
Version control systems provide two important features required for working in a team:
a history of the work submitted by the team
a way to coordinate and integrate this work.
Maintaining history is important so that one can compare the current work against previous, revert to older work that is better, etc. Coordinating the work is critical so that there exists one definition of the current project state, containing the integrated work of the team. This coordination is provided via the stream model.
An optimistic model is one where any member of the team can make changes to any resource he/she has access to. Because two team members can release to the stream changes to the same resource, conflicts can occur and must be dealt with. This model is termed optimistic because it is assumed that conflicts are rare.
Usually resources don't exist in isolation: they typically contain implicit or explicit dependencies on other resources. For example, web pages have links to other web pages, and source code has references to artifacts described in other source code resources. No resource is an island.
As resources are released to the stream, these dependencies can be affected. Ensuring the integrity of the dependencies is important because the stream represents the current project state: at any point a team member could take the stream contents as a basis for new work.
The ideal work flow therefore is one in which the stream integrity is preserved.
The ideal work flow proceeds as follows:
Start fresh: Before starting work, get caught up with the current stream state. If you are sure that you have no local work that you care about, the fastest way to get caught up is to select the projects you are interested in from the stream and select "Add to Workspace". This will blanket overwrite your local resources with those from the stream.
Make changes: Work locally in your workbench, creating new resources, modifying existing ones, saving locally as you go.
Synchronize: When you are ready to release your work, Synchronize with the stream.
Catch up: Examine incoming changes and add them to your local workbench. This allows you to determine if there are changes which might affect the integrity of what you are about to release. Resolve conflicts. Retest, run integrity checkers (e.g. check for broken hypertext links, ensure your code compiles, etc.).
Release: Now that you are confident that your changes are well integrated with the latest stream contents, release your changes to the stream. To be prudent, you may repeat step 4 if there are again new incoming changes.
Of course this is an ideal workflow. Under certain conditions you may be confident that the incoming changes do not affect you and choose to release without catching up. However, in general team members should make an effort to follow a flow similar to the above in order to ensure that the stream integrity is not accidentally compromised.