Ewat
Ewat

Reputation: 200

When was a clearcase snapshot view last updated?

I want to find the timestamp when a clearcase snapshot view was last updated. By this, I mean the time when the last "cleartool update" was started.

Or, said another way, if I was going to make a dynamic view with a timestamp, what timestamp should I use to make it exactly equivalent to a given snapshot view?

The only way I can come up with is to look for the log file called update.[timestamp].updt that is written to the root of the snapshot view directory on every view update. But in some cases, I don't have access to this file. Is there another way?

The following command looks like it comes close, but I'm not sure if it's what I want -

ewat> cleartool lsview -prop -full ewatkins_11122_s_ewatkin4
  ewatkins_11122_s_ewatkin4 /scfs3/vws_u/ewatkins/ewatkins_11122_s_ewatkin4.vws
Created 19-Apr-11.23:42:13 by ewatkins.cdev@dscddy02
Last modified 02-Jun-11.16:28:45 by [email protected]
Last accessed 02-Jun-11.16:28:45 by [email protected]
Last read of private data 02-Jun-11.16:28:45 by [email protected]
Last config spec update 25-Apr-11.15:50:13 by [email protected]
Last view private object update 02-Jun-11.16:28:45 by [email protected]
Text mode: unix
Properties: snapshot readwrite
Owner: arbor.hyperion.com/ewatkins : rwx (all)
Group: arbor.hyperion.com/cdev : r-x (read)
Other:                  : r-x (read)
Additional groups: arbor.hyperion.com/essbase_prerel

The above output was taken right after I did a snapshot update. You can see that last modified, last accessed, last read, and last update have all been set to the time when the snapshot update finished -- 02-Jun-11.16:28:45.

This time is not quite what I want. Assume the snapshot update takes several minutes. If I make a dynamic view with this timestamp, the dynamic view will have any new files that were checked in during the several minutes while the update was running.

Am I out of luck unless I have the update.[timestamp].updt file?

Upvotes: 2

Views: 1682

Answers (2)

Ewat
Ewat

Reputation: 200

I think I answered my own question --

The timestamp in the update.<timestamp>.updt is the moment that the "cleartool update" was started, but it's the time on the local machine - which may be different from the time on the clearcase server machine.
For instance, the time on my two machines are different by about 3 minutes. So this timestamp is not what I'm looking for. Of course, I could just use NTP to synchronize the times, but I found something else interesting...

"cleartool update" does not update the "Last config spec update" time.

"cleartool setcs -current" DOES update the "Last config spec update" time to the moment the update started.
And since we're using Hudson to manage our snapshot views, and the Hudson clearcase plugin does setcs -current, then we are in luck!
The "Last config spec update" time is exactly what I want, and it's even the time on the clearcase server, not the local host!

Upvotes: 2

VonC
VonC

Reputation: 1323593

From what I tested, I don't think that you would end up with any version newer than the "last config spec update" date (while the last modified date is entirely managed by the OS)

So you should be ok doing a dynamic view with the "Last config spec update" time-based rule.

See the IBM man page "How snapshot views are updated"

The update operation accounts for the fact that updates are not instantaneous. As your view is updated, other developers may check in new versions of elements that the load rules for your view select. To avoid loading an inconsistent set of versions, the update operation ignores versions in the VOB that meet both of the following conditions:

  • The version was checked in after the moment the update began.
  • The version is now selected by a config spec rule that involves the LATEST version label.

The update adjusts for the possibility that the system clocks on different hosts in a network may not be synchronized (that is, clocks are skewed).

Upvotes: 1

Related Questions