Question

I need to create a Clearcase label script to run on a UNIX server.

Labels will not always be on the latest build and the script needs to be run via a manual process.

It will label every file a branch of code at a version (currently selected by a timestamp-timestamp is from a Hudson build engine which will create these scripts and ftp to the Unix server).

The build server(Windows) is a different machine than what the script will be run on(UNIX).
The build server currently populates then and builds from a snapshot view.
Users do have clearcase access and permissions.

The code is never built from the UNIX machine- it is a central location where multiple people can go to label the code.

Is it necessary to recreate the view on the UNIX server to label(i.e. do I need to start the view, label and then stop view)? Or could I do something more lightweight?

Answer 1

For this kind of task, I definitively recommend using one dynamic view, combined with a time-based selection rule.

You can:

• first create a config spec file with the right selection rule based on timestamp used by the build process
• set the config spec to your view (cleartool setcs /path/to/config/spec/file, see setcs)

The all process doesn’t require to stop/restart the view.
And since it uses a dynamic view, there is no ‘update’ time to wait (no file to load).

---

The OP adds in the comments:

What is the benefit of labeling the current dynamic view(set by a time in the config spec) vs labeling the contents of the dynamic view via selecting a version based on timestamp?
(I take this all to mean it is impossible to label without being in a view)

First, yes, you need to be in a view to label.
And ClearCase will label what it sees in the view (i.e. the versions selected by the current config spec)

Now it is better to have a dedicated dynamic view for that kind of operation because that avoid messing with any other view you might be using for any other operation.
This dynamic view can be the only one needed for labeling operation, and by setting the right time-based config spec selection rule, you ensure labeling what was actually used at the time of your build.