1

I am trying to understand how long ClearCase operations take after performing the add to source control operations.

If I am working through a CCRC snapshot view and I add a file to source control, how long will it take for the changeset to be updated with the new line, and how long until the operation completes will the new file be available under a dynamic view pointing to the stream that the file was checked into?

Is there any way to speed up that process by invoking a manual update of the dynamic view or something?

Regards,

Andrew

Andrew
  • 293
  • 6
  • 14

2 Answers2

1

how long will it take for the changeset to be updated with the new line

As soon as you checkout a file, selecting an activity, it will update the chenge set of said activity immediately.

A dynamic view would reflect that file only after you check in (through your web snapshot view in CCRC), and that update would also be near instantaneous.
To speed up, you can refresh the dynamic view, or do a cleartool ls in the directory you want to see updated.

In each case, when you are doing a checkout or a checkin through CCRC, you are posting an http request to the CCRC server which in turn complete the operation with the ClearCase Vob/View server.
So once the checkout/checkin is completed, any other ClearCase view (CCRC or not) would be ready to reflect the changes.
The only part which takes time is the communication between the CCRC client and the CCRC server. That server being usually on the same LAN as the ClearCase server, the ClearCase command itself executes fairly quickly.

"fairly quickly" turned out too slow for the OP's need: a postop trigger on checkin.

That trigger use a ClearCase dynamic view on the server side, and has to introduce a sleep on the element checkin (on mkelem) in order for the second call of that trigger (on the parent directory being checked in) to properly detect the new created file.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • When I perform `Add to source control` ClearCase checks in the new file first and then checks in the updated directory version.This means that if I enter into the view and perform `dir` after the first checkin it won't display the new file, correct? I am asking this because the trigger that I am writing works perfectly when modifying existing files, but when I add a new file I cannot retrieve it from the dynamic view since it only exists after the updated directory version is checked in. Does this make sense? – Andrew Feb 13 '13 at 08:18
  • @Andrew It does make sense. Actually an "add to source control" will checkout the parent directory, mkelem (create the element) and checkin the parent directory. BUT, if the parent directory was *already* checked out, then it will be *left* checked out by the "add to source control". In both cases, a preop trigger on `mkelem` would not see the element in any other view than the one used for said `mkelem`, because of the checked out parent directory. – VonC Feb 13 '13 at 08:25
  • My trigger is a postop on the `checkin` operation, so I was hoping to see the file after the first checkin operation. The parent directory is not checked out when performing the "Add to source control". Under these circumstances should I see the checked in file in the dynamic view? The `mkelem` is being done on a CCRC snapshot view. – Andrew Feb 13 '13 at 08:32
  • @Andrew No, a postop on checkin would be triggered too soon when the element is checked-in. But it should also be called when the parent directory is check-in. However, a/ there is no guarantee that the directory will actually be checked in by the add to source control, b/ a `cleartool ls` would still be needed for the dynamic view to refresh its content (you can try it in your trigger). – VonC Feb 13 '13 at 08:38
  • I tried `cleartool ls` within the view after the first checkin and the new file is not present. Since the trigger is set for the `checkin` operation, it automatically fires again straight after the first checkin, but this time for the folder. The `cleartool ls` doesn't display the new file either. If, however, I put a sleep for 30 seconds in the script, the second time the trigger fires the new file is present, which I attribute to the ClearCase update latency, right? It makes no sense to add a sleep because it punishes people who do a normal checkin and not an add to source control. – Andrew Feb 13 '13 at 08:50
  • @Andrew did you try a `cleartool ls` in the *parent* directory of the parent dir, ie the grand-parent dir of the element added to source control? And then a second `cleartool ls` in the parent dir itself, in hope of seeing the new element? – VonC Feb 13 '13 at 08:56
  • I have now, `cleartool ls` in both grand-parent and parent dirs. They don't display the new element in the dynamic view, both for checkin of element first and then parent dir second. Would it make sense to have two triggers, one on post `checkin` and one on post `mkelem` in the hopes of managing the "add to source control" action differently (such as adding a sleep in the `mkelem` trigger only)? – Andrew Feb 13 '13 at 09:02
  • @Andrew the sleep might help. Another lead would be to check if the dynamic view can access the new elements through its extended pathname (http://stackoverflow.com/questions/987427/why-cant-perl-find-my-file-that-is-in-clearcase/988904#988904) – VonC Feb 13 '13 at 09:28
  • I am already using the extended path name and it didn't change anything. This is probably because even though I have the version, the directory isn't referencing it yet. Here's what I did. I only make the script sleep if the checkin is being made for a folder. This way the previous checkin (the element) will have time to appear in the dynamic view. There are many cases where this could fail, but since no subfolders will be made and checkins will only be performed without the directory already being checked out, I can permit the script to include certain assumptions. – Andrew Feb 13 '13 at 10:07
  • @Andrew that does look good, then. I have edited my answer to make your solution more visible. – VonC Feb 13 '13 at 10:25
1

Theoretically, it should be instant. As soon as the add finishes, the dynamic view should see the new file. In reality, it might take longer due to the nature of ClearCase and its view processes.

Every view has a process running on the view server (local or remote), and this process needs to query the VOB server to get the changes.

In our ClearCase environment, we see many lags that are probably the combination of a loaded server and network traffic.

Bottom line - should be quick (seconds), but not instant. If it takes longer, you should try and see what might be slowing the processes down.

Eldad Assis
  • 10,464
  • 11
  • 52
  • 78