Dave- is it possible for this variable to be set at the Server level? I *strongly* suspect that everybody who cares about the local "Last Modified" date would prefer to preserve the AccuRev timestamp for files that are populated to their local filesystems.

Sorry, please disregard my post. I mistakenly assumed the "fileModTime" from show -fx wspaces was somehow displayed in the GUI. It is not. I assume it's used internally by AccuRev and has no real value to the user.

FWIW, my post is correct on how this value is updated (with no ACCUREV_USE_MOD_TIME; I didn't test with it). I installed v7.2 today (using my trusty two-user license!) to verify. This should also help make my participation on the forum a lot more fun and meaningful going forward.

Cheers,
Brian

Here's what I recall: When the update operation succeeds, the Last Modified date is the date and time of the oldest non-member element in the workspace with (modified) status. If no such element exists, it is the date and time the update command was issued.

Hello James,

    Is the user running with the environment variable "ACCUREV_USE_MOD_TIME" set? 

   If this variable is set to 1, the AccuRev commands co, pop, purge, revert, and update preserve timestamps when copying versions from the repository into a workspace.

  For "update" the documentation states: 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.)

  co, pop, and revert state similar behavior.

  If this environment variable is set, does it meet the user's needs?

Cheers,

Dave