2

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 ewatkins.cdev@ewatkin4.us.oracle.com
Last accessed 02-Jun-11.16:28:45 by ewatkins.cdev@ewatkin4.us.oracle.com
Last read of private data 02-Jun-11.16:28:45 by ewatkins.cdev@ewatkin4.us.oracle.com
Last config spec update 25-Apr-11.15:50:13 by ewatkins.cdev@ewatkin4.us.oracle.com
Last view private object update 02-Jun-11.16:28:45 by ewatkins.cdev@ewatkin4.us.oracle.com
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?

Ewat
  • 200
  • 1
  • 8

2 Answers2

2

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!

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Ewat
  • 200
  • 1
  • 8
1

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).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks - this confirms my suspicions about how updates work. But "last config spec update" won't solve the problem, unfortunately. We're using Hudson to manage our build process, so the config spec is only changed occasionally, while "ct update" is run pretty often. You can see an example of this in the text above - the "last config spec update" was april 25, but the last "ct update" was on june 2. Any other ideas? – Ewat Jun 05 '11 at 18:28
  • @Ewat: you need to have a script which: a/ memorize that last update date, b/ performs the update through `cleartool update`. Then you can use that information for your time-based dynamic view. But you won't find the "last update date" directly from ClearCase. – VonC Jun 05 '11 at 18:52
  • Thanks! Sounds like the way to go. – Ewat Jun 07 '11 at 23:37