edcs

Product	Command type
ClearCase®	cleartool subcommand
ClearCase Remote Client	rcleartool subcommand

Platform
UNIX®
Linux®
Windows®
Web

Description

For information about specifying config spec content, see the config_spec reference page. As a rule, you never edit a UCM config spec; see the config_spec reference page for exceptions to this rule.

This command does not require a product license.

General information about the edit session

The edcs command revises a view's config spec by invoking a text editor on an existing config spec. The config spec can be one of the following:

The view's current config spec
A text file that you want to edit and then make the view's config spec. (If you don't need to edit the file, use setcs.)

Using the edit session in ClearCase on UNIX or Linux

In ClearCase, if the working directory view differs from the set view (established by the setview command), edcs displays a warning message and uses the working directory view. The text editor invoked by edcs is specified by the environment variable WINEDITOR (first choice), VISUAL (second choice), or EDITOR (third choice). If none of these EVs is set, vi(1) is invoked.

When you invoke edcs without specifying the file argument, ClearCase runs the text editor from the /tmp directory. When you end the editing session and set the config spec, the config spec is stored in the view storage directory. However, if you perform other operations from within the text editor, ClearCase executes those operations from /tmp, not from the directory where you invoked edcs. For example, in a vi editing session, the command :w prev-cs copies the contents of the config spec to a file named prev-cs and stores prev-cs in /tmp.

Using the edit session in ClearCase on Windows

In ClearCase, the text editor invoked by edcs is specified by the VISUAL environment variable; if this EV is not set, edcs uses the value of the EDITOR environment variable. If neither EV is set, edcs invokes the Notepad.

After the edit session

At the end of the edit session, there is a confirmation step. For dynamic views, this prompt is

Set config spec for view “view-tag”? [yes]

For snapshot views, this prompt is

Set config spec and load snapshot view “view-tag”? [yes]

If you answer yes, the modified config spec is set as the view's config spec. (In a snapshot view, there is an additional confirmation step if the edits to the config spec cause elements to be unloaded from the snapshot view.)

Note: In a snapshot view, setting the config spec initiates an update -noverwrite operation and generates an update logfile with the default name and location. (For information about this logfile, see the update reference page.) To execute this command on the command line, you must be in or under the root directory of the snapshot view.

If you answer no, the command is canceled; the view retains its current config spec.

Exporting view config specs in ClearCase on UNIX or Linux

If you modify the config spec of a view that is being exported for non-ClearCase access, make sure that all users who may currently have the view mounted for that purpose unmount and remount the view. Unmounting and remounting the view ensures access to the correct set of files as specified in the updated config spec.

Options and arguments

Specifying the view

Default: Edits and sets a config spec for the current view.
–tag view-tag: The view tag of any dynamic view; the view need not be active.
Note: To edit the config spec of a snapshot view, you must be in that view. However, in a snapshot view, you can use this option to edit the config spec of a dynamic view.

Specifying the config spec file

Default: Edits the view's current config spec.
file: The path name of a file to be used as input to the edit session. If the file does not exist, edcs creates it.

Handling hijacked files

Default: All hijacked files are left in the view with their current modifications.
–ove/rwrite: Overwrites all hijacked files with the version selected by the config spec.
–ren/ame/: Renames hijacked files to filename.keep and copies the version in the VOB selected by the config spec into the view.

Determining the modification time stamp

Default: The initial default is set by the mkview command. Thereafter, the most recently used time scheme is retained as part of the view's state and is used as the default behavior for the next update.
–cti/me: Sets the time stamp of a file element to the current time, that is, the time at which the version is copied into the view. –ctime has no effect on directories (directories always use the current time).
–pti/me: Sets the time stamp of a file element to the time at which the version was checked in to the VOB. –ptime has no effect on directories. (Directories always use the current time.)

Examples

The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.

The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.

Edit the config spec of the current view.
cmd-context edcs
Edit the config spec of the dynamic view with the view tag jackson_fix.
cmd-context edcs –tag jackson_fix
Use a text file named cspec_rel3 as input to an edit session, producing a new config spec for the current view.
cmd-context edcs cspec_rel3