Note: The following discussion includes a description the traditional AccuRev Timestamp Optimization algorithm. AccuRev Release 5.4 introduced an new, optional, client-oriented approach to timestamp optimization. This new algorithm is discussed in the Java GUI on-line help (
AccuRev On-Line Help Guide), at
Timestamp Optimization: Controlling the Determination of (modified) Status on page 97.
This section describes the processing of the Update command in detail. It’s not as simple as “get all the new versions”, because AccuRev takes care not to overwrite version-controlled files that you have changed, but whose changes have not yet been preserved in the repository.
•
|
It uses the –n option to stat, which restricts the search to version-controlled files that you have modified but are not in the workspace’s default group — the status of such “non-member” files includes the (modified) indicator but not the (member) indicator. It’s safe to ignore default-group files, because these are never affected by an Update.
|
•
|
It uses timestamp optimization to speed the file search: it ignores files whose timestamps precede the workspace’s scan threshold (the time that the workspace was most recently updated or otherwise searched for modified files). If you modify a file by overwriting it with a file with an old timestamp, the file will be ignored in this step. This can cause problems in Step 5 below.
|
•
|
If environment variable USE_IGNORE_ELEMS_OPTIMIZATION is set to TRUE (the value is case-insensitive), then it uses the value of environment variable ACCUREV_IGNORE_ELEMS to ignore certain pathnames in the file search. If an ignored file actually has (modified) status, an error will occur in Step 5 below.
|
•
|
A non-member file that is due to be updated has (modified)(overlap) status. By default, the presence of one or more such files causes the update to terminate immediately, without updating any file. But you might be able to enable the update to proceed if you invoke an update option — update –m in the CLI, user preference Update Resolves Trivial Merges in the GUI. With this option invoked, the update proceeds only if a trivial merge can be performed for each file with (modified)(overlap) status. (The backing-stream version can be merged with the workspace-tree file automatically, because there are no conflicts that require manual intervention.)
|
If AccuRev is processing files with (modified)(overlap) status (see
Step 2 above regarding
update -m), it automatically merges the backing-stream version with the file in the workspace tree, instead of simply overwriting the file. No checksum of the workspace-tree file is performed for such elements.
6.
|
If all the recently created versions identified in Step 4 were successfully delivered to the workspace:
|
The timestamp optimization is most effective when it enables AccuRev to ignore as many files as possible. Accordingly, AccuRev takes advantage of opportunities to validly advance the scan threshold to a later time:
•
|
The CLI command stat –n advances the scan threshold to the point in time just before the earliest timestamp among the files it finds (modified files that are not members of the workspace’s default group). This preserves the validity of the timestamp optimization principle: for file elements that are not in the workspace’s default group, the timestamp of a modified file is later than the workspace’s scan threshold.
|
If stat –n does not find any non-member modified files, it advances the scan threshold to the time that the command began.
If stat –nO finds non-member modified files whose timestamps precede the scan threshold, it moves the scan threshold
backward, in order to preserve the timestamp optimization principle described above.
The Update command is not implemented as an atomic operation, and it is not recorded as an AccuRev transaction. Transactions are used to organize and serialize changes to the repository, not to the workspace trees that implement user “sandboxes”. An
Update can take a significant amount of time, and is sometimes interrupted before it completes — by user request, by network failure, by loss of telephone connection, etc.
For purposes of discussion, assume that your workspace, talon_dvt_mary, has a current update level of 84, that the highest transaction in the repository is 109, and that 45 files in your workspace would be involved in a complete
Update. You can monitor transaction levels using the CLI command
show wspaces:
The first 84 indicates the workspace’s target update level; the second
84 indicates the current update level.
•
|
The Update command sets the target update level to 109, then proceeds. If Update processes all files successfully, it raises the current update level to the target:
|
But if the Update does not complete successfully, the target update level remains unchanged. A subsequent
show wspaces reveals that the target update level differs from current update level:
Consider the case in which Update was interrupted — say, after it had processed 29 out of the 45 files to be updated. When a subsequent
Update command is issued:
(See Step 5 above for a discussion of the checksum process.)
Now consider the case of an incomplete Update, due to one or more “crc mismatch” errors. Suppose that only 42 out of 45 files are updated, because 3 files fail the checksum match. You must fix the problem before issuing another
Update.
If those three files had been overwritten by mistake, you can restore the proper versions using the Revert to Backed Version command (CLI:
purge). Then, a second
Update brings the new versions of those 3 files into the workspace.
When it begins executing an Update command, AccuRev determines whether the preceding update of the workspace completed successfully or not:
•
|
The Update completed successfully if the target and current update levels are the same.
|
•
|
The Update was incomplete if the target and current update levels differ.
|
If the preceding update was incomplete, AccuRev performs two updates at once. First, it performs a “fixup” update that completes the preceding update; then it performs an additional update (if necessary), to process changes made to the backing stream after the incomplete update. During the “fixup” update, AccuRev avoids the unnecessary work: it does not retransfer files that were successfully delivered to the workspace during the incomplete update.
•
|
You issue an Update, but it fails to complete. At this point, the workspace’s target update level is 109, but its current update level is still 84.
|