Idea ID: 2870832

More Elegant Handling of "Last Modified"

Status : New Idea

One of my users complained about the "Last Modified" date, and its inconsistent handling in AccuRev. When looking at a stream, the "Last Modified" date reflects the most recent promotion of that file to that stream; when looking at a workspace, the "Last Modified" date simply reflects the creation of the file in the local filesystem (which is *not at all* useful) or the most recent modification in the local filesystem.

AccuRev should either:
1) Populate workspace files with a "Last Modified" date of the file in the basis stream (even if this time is in the past)
2) Provide some way to distinguish between "Last Modified (Filesystem)" and "Last Modified (AccuRev)" in its display

Tags:

Labels:

Usability
  • 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