incorporate other people's changes into your workspace
accurev update [ -r <reftree> ] [ -i ] [ -m ] [ -fx ] [ -O ]
[ [ -t <transaction-number> ] | [ -s <stream-name> -t <transaction-range>
The update command copies versions from your workspace’s backing stream into your workspace. This has the effect of incorporating other people's changes, which they have promoted to the backing stream, into your workspace. It can also be used, with the -s and -t options, to inspect a stream for changes that occurred within a range of specified transactions; you might want to use the -s and -t options to monitor a stream that you use for builds, for example.
update replaces only those files in your workspace that are stale. (Use update -i to list stale files.) It does not replace files that you have modified, whether you have saved them with keep or not. (But update can attempt to perform merges on some modified files — see Handling of (modified) Files / Merge on Update below.)
Timestamps on Updated Files
By default, each file copied into your workspace by this command has its timestamp set to the current time. If environment variable ACCUREV_USE_MOD_TIME is set, the timestamp is set to the time the version was originally created. (Note: that’s the time the version was created in some user’s workspace stream, not the time it was subsequently promoted to the backing stream.) Setting this environment variable may defeat an optimization in the stat command. See Optimized Search for Modified Files.
update causes a new value to be recorded for the update level workspace parameter.
When an update command completes, the workspace is fully up-to-date. That is, your workspace has incorporated changes that were recorded in the depot as transactions, up to and including the most recent transaction, say #4167. In this case, transaction #4167 is said to be the update level of your workspace. Subsequent changes, made by you and by other users, might cause the depot’s most recent transaction to increase to #4328, but your workspace’s update level remains at #4167 until you perform another update.
A workspace’s update level is displayed by the show wspaces command:
> accurev show wspaces
gizmo_dvt_john C:/wks/gizmo/dvt_john moped 6 56 47 1 0
In this example, the workspace’s update level is transaction #47. (The “target level” is transaction #56, indicating that the most recent update of this workspace was interrupted before it could be completed.)
Handling of (modified) Files / Merge on Update
If you have changed a file in your workspace that is due to be updated, and the file is not yet a member of the workspace’s default group, the file has (modified)(overlap) status. If there are one or more such files in your workspace, AccuRev’s default is to cancel the update command:
Some of the elements in your workspace are overlap/modified and are not in your default group.
This default protects your data: a simple update would overwrite your changes to the file, which haven’t been preserved anywhere in the AccuRev repository.
You have several alternatives for handling this situation:
- anchor or keep those files, then update the workspace. The file(s) that you’ve processed with anchor or keep won’t be updated.
- purge those files, then update the workspace. The file(s) that you’ve processed with purge will be updated.
You can use the -m (“merge automatically”) option. An update -m command succeeds only if each file with (modified)(overlap) status can be merged automatically — that is, non-interactively — with the backing-stream version. If this condition is satisfied, the update proceeds and each such file is handled as follows:
- AccuRev performs the automatic merge, replacing the file in your workspace with the merged version. This functionality parallels that of the CVS version-control system.
- No keep or merge is recorded in the AccuRev database.
- The backing-stream version becomes the predecessor of the file in your workspace (because the workspace’s update level has changed).
If you have changed a file in your workspace that is not due to be updated, and the file is not yet a member of the workspace’s default group, the file has (modified) status — but not (overlap) or (member). In this case, update simply bypasses that file (whether or not you use -m). After the update finishes, all such files retain their (modified) status in the workspace.
Update and Replication
The update operation works as follows when you execute it on a client that uses a replica server:
- An implicit replica sync command is performed, copying database transactions from the master repository to the replica repository. This brings the replica database completely up to date.
- A stat operation is performed on the replica server, to determine the state of the workspace stream and its backing stream.
- Data files representing new versions of elements are copied from the file storage area in the master repository to the file storage area in the replica repository.
- Data files are copied from the replica repository to your workspace tree. In addition to the files retrieved from the master repository in the preceding step, this can include files that have already been “downloaded” to the replica repository through other users’ commands.
- On both the replica server and the master server, the transaction level of the workspace is set to the most recent transaction (or to the transaction specified with update -t).
Updating Symbolic Links
On Windows systems, a symbolic link to a directory is implemented as a junction point at the file system level. Accordingly, such links are not supported for FAT/FAT32 file systems. When updating a workspace located in a non-supported file system, an existing symbolic link to a directory generates an error (and update creates an empty, standard directory at the link location):
Re-linking "dir01sub03.mylink" - failed
Updating Reference Trees
Use update -r to update a reference tree. To keep a reference tree as up-to-date as possible, call update from a job-scheduling program, such as cron (UNIX/Linux) or at (Windows). You can also use AccuRev's server-post-promote-trig trigger to update reference trees automatically.
Implementing Partial Workspace Updates
update always processes all the elements in a workspace; there is no option to specify a subset of elements to be updated. You can accomplish this, however, using a series of merge commands. See Using Merges to Implement a Partial Update of Your Workspace in the merge reference page.
|-i||Show which files would be updated, but don’t perform the update.|
|-m||Enable the “merge on update” capability. See Handling of (modified) Files / Merge on Update above.|
|-r <reftree>||Specify a reference tree to be updated. (Default: update the current workspace.)|
|-s <stream-name> -t <transaction-range >||Specify a stream and range of transactions you want to inspect for changes. When you use -s, you must use -t to specify the range of transactions (-t <#>-<#>).|
|-t <transaction-number >||
Update the workspace to the specified transaction. For example, if you specify
Note that the transaction number you specify must be greater than the workspace update level. For example, if the current workspace update level is #40, you can specify a transaction number of #41 or more, up to the current transaction level in the depot.
You can see the current workspace update level in these places:
When the -s option is used, -t is used to specify a range of transactions for the specified stream in the format -t <#>-<#>, or
|-fx||Display the results in XML format.|
|-O||Override the optimized the search for modified files. When -O is used, all files are considered, even those whose modification times have not changed since the last time the workspace was updated or searched for modified files. Having to check all files, regardless of modification time, slows update performance.|
List the files that would be copied into the workspace by an update command:
> accurev update -i
Copy recently created versions into a particular reference tree:
> accurev update -r /usr/alpha_test/gizmo4572