Update: Incorporating Others’ Changes into Your Workspace

As users work independently of each other, the contents of their workspaces increasingly diverge. Typically, some of the differences between workspaces are inconsistencies. For example, changes that John makes in a report-library routine might cause errors in the report program that Mary is writing. To minimize the time and effort required to resolve inconsistencies during the integration phase of a project, it makes sense to have users synchronize their workspaces on a regular basis.

Synchronization does not mean incorporating data into your workspace directly from one or more other workspaces. Instead, synchronization involves copying data into the workspace from the stream to which all team members Promote their changes.

This figure shows how to invoke the Update command from the File Browser toolbar. Update is also available from the File and context (right-click) menus.

Tip: You can Update your workspace from any File Browser mode, but the Incoming Changes Mode shows you exactly how your workspace will change.

Note: The stream’s role as a provider of data, through Update operations, to a set of workspaces motivates the term backing stream. Think of restocking a store’s shelves with merchandise retrieved from "the back room".

Note:

So updating your workspace copies versions of certain files from the backing stream to the workspace, overwriting/replacing the files currently in the workspace. But which files? Update changes a file if:

There is a newer version in the backing stream, and
The file is not currently active in your workspace.

Update will not overwrite an active file, even if there is a new version of it in the backing stream. No matter how good someone else’s code is, you do not want his changes to wipe out the changes that you have been making! This situation is another instance of an overlap, which was introduced in Promote: Making Your Private Changes Public. You can encounter an overlap during a promote (if you are trying to make your private changes public), or during an update (if you are trying to bring already public changes into your private workspace). You can use the merge operation to resolve all such overlap situations. See Merge: When Changes Would Collide.

Update handles namespace changes as well as content changes. Thus, if your colleague renamed a file and promoted the change, an update will cause the file to be renamed in your workspace. And if your colleague removed a file using the Defunct command, an update will cause the file to disappear from your workspace.

More About Update

Here is how AccuRev prevents an update from overwriting your changes: the first thing Update does is to analyze your workspace, determining whether each version-controlled file is active or inactive. Initially, all the files in a workspace are inactive, each one is a copy of some version in the repository. (For each version-controlled file, AccuRev keeps track of which particular version.)

A file is deemed to be active in your workspace if you have created a new version of it, using the Keep, Rename, Move, or Defunct command. (There are other commands that "activate" a file.) When Update copies versions from the repository into your workspace, it skips over all active files.

Note: Update can tell if you have modified a file but have not yet stored the changes in the repository as a new Keep version. It uses time-stamps and checksums to determine this. The presence of such files prevents the update from proceeding if updating would overwrite one or more of them with the backing-stream versions. You can use the Anchor command to activate such files, enabling Update to do its work.