update

Updates elements in a snapshot view or Attache workspace

APPLICABILITY

SYNOPSIS

• ClearCase and ClearCase LT-Update elements using the graphical update tool:

update -g·raphical [ pname ... ]

• ClearCase and ClearCase LT-Update elements from the command line:

update [ -print ] [-f·orce ] [ -ove·rwrite | -nov·erwrite | -ren·ame ]

[ -cti·me | -pti·me ] [ -log pname ] [ pname ... ]

• ClearCase and ClearCase LT-Load elements from the command line by specifying one or more load rules:

update -add·_loadrules [ -print ] [-f·orce ] [ -ove·rwrite | -nov·erwrite | -ren·ame ]

[ -cti·me | -pti·me ] [ -log pname ] pname [ pname ... ]

• Attache:

update { [ -print [ -since date_time] |

[ -all |-since date_time]
[ -ove·rwrite | -nov·erwrite ] [ -pti·me ] [ -compress ] }
[ -r·ecurse ] [ -log pname ] pname...

DESCRIPTION

ClearCase and ClearCase LT-Updating Loaded Elements

For one or more loaded elements, the update command does the following:

• Reevaluates the config spec to select a versions of loaded elements in the VOB, and loads them if they differ from the currently loaded element versions

• Unloads the file or directory from the view if a loaded element is no longer visible (that is, a new directory version doesn't have an entry for the element). To unload a directory element, ClearCase and ClearCase LT

• Recursively delete all loaded elements

• Rename the directory to directory-name.unloaded if necessary, thus preserving all view-private files and view-private directories.

• If the version in the snapshot view is different from the version in the VOB selected by the config spec, copies the version selected by the config spec into the view. The version in the view can be different if, for example, the selected version in the VOB is newer, or if a label is attached to the selected version in the VOB, but not to the version in the view

update does not apply to files or directories that are checked out to the current view.

If update cannot access a VOB (perhaps due to problems in the network), any elements from that VOB remain loaded, but are put in a special state (rule unavailable).

The update command accounts for the fact that VOB elements specified by your config spec may change while an update is in progress. To avoid loading an inconsistent set of element versions, update ignores versions that meet both of the following criteria:

• The version is selected by a config spec rule that specifies the LATEST version label.

• The version was checked in after the moment the update operation began.

update also accounts for the fact that the system clocks on different hosts may not be synchronized.

When issued from a snapshot view,the following cleartool commands invoke update at the completion of the command:

• edcs

• findmerge (only when used to merge versions of a directory)

• ln

• merge (only when used to merge versions of a directory)

• mkdir

• mkelem

• mv

• rmname

• setcs

• uncheckout

ClearCase and ClearCase LT-Loading New Elements

The form of the update command that specifies the -add_loadrules option enables you to add new load rules to your config_spec and load the elements that those rules specify.

Attache

This command downloads the specified files to the workspace.

RESTRICTIONS

None.

OPTIONS AND ARGUMENTS

ClearCase and ClearCase LT

USING THE GRAPHICAL UPDATE TOOL. Default: The update is performed in the command window.

-g·raphical

Invokes the graphical update tool.

USING THE PREVIEW MODE. Default: None.

-print

Produces a preview of the update operation: instead of copying or removing files, update prints a report to standard output of the actions it would take for each specified element.

CONFIRMATION STEP. Default: update prompts for confirmation of the elements to be updated. However, update does not in all circumstances prompt you to confirm all the elements to be updated. Sometimes there are no confirmation prompts when you update elements, even though you have not specified -force.

-f·orce

Suppresses the confirmation prompts.

HANDLING HIJACKED FILES.  Default: Leaves all hijacked files in the view with their current modifications (-noverwrite).

-ove·rwrite

Overwrites all hijacked files with the version selected by the config spec.

-nov·erwrite

Leaves all hijacked files in the view with their current modifications.

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

SPECIFYING A FILE TRANSFER LOG.  Default: A log file named update.timestamp.updt that is written to the root of the snapshot view directory.

-log pname

Specifies a log file for the operation. The log file lists the actions taken by the update command, as well as an indication of any errors that occur during the operation. To suppress generation of the log file, use -log /dev/null (UNIX) or -log NUL (Windows).

SPECIFYING NEW LOAD RULES.  Default: None.

-add_loadrules

Specifies that the pname argument is a new load rule. The new rule is appended to the view's config spec, and the elements it specifies are loaded.

SPECIFYING THE ELEMENTS TO BE UPDATED OR ADDED.  Default: If you do not specify -add_loadrules, the current snapshot view; if you specify -add_loadrules, none.

pname ...

If you do not specify -add_loadrules, this argument specifies the files and/or directories to update. All specified directories, including the root directory of the snapshot view, are updated recursively.

If you specify -add_loadrules, this argument is interpreted as a new load rule. The elements specified by the rule are loaded and the rule is appended to the config spec of the current view. pname must be either a pathname relative to your current location in the directory structure of the snapshot view or an absolute path that includes the snapshot view path.

Attache

SPECIFYING THE FILES TO BE UPDATED.  Default: None.

pname...

Specifies the files, directories, and/or links to be updated. For a pname containing a symbolic link, Attache updates a copy of the file or directory the link points to, rather than the link itself. Wildcard patterns are expanded with reference to the view. In addition, arguments of the form @pname can be used to add the contents of the local file pname as pathname arguments. The pathname arguments can contain wildcards (most useful for excluding particular files; see the wildcards reference page), and must be listed in the file one per line, or also be of the form @pname. Specifying a relative pathname for @pname begins from Attache's start-up directory, not the working directory, so a full local pathname is recommended.

-all

Specifies that all files are to be downloaded to the Attache workspace.

-since date_time

Downloads to the Attache workspace all files checked in since the time specified in date_time.

DISPLAY FILES TO BE UPDATED.  Default: None.

-print [ -since date_time]

Displays the files that need updating, but does not update them in the Attache workspace. If -print is used, a reference time must be specified. -since displays files updated since date_time. A project config file which has been used to do an update can also be specified. The config file is specified as @filename for the pname argument. For each config file used to do an update, Attache remembers the last update time and uses it for the next update with that config file.

SPECIFYING HOW THE FILES ARE TO BE UPDATED.  Default: When a directory is specified, its file contents are updated. If a destination file already exists that is identical in contents with the source file, it is not overwritten. If an existing destination file is read-only and differs from the source, it is always overwritten. If the destination file exists and is writable, an overwrite query is issued.

-ove·rwrite

Suppresses the query and causes all writable files to be overwritten.

-nov·erwrite

Suppresses the query and causes no writable file to be overwritten.

-pti·me

Causes the last-modified time stamp of the destination file to be set to that of the source file. -ptime has no effect on directories.

-compress

Causes files to be compressed while being uploaded and uncompressed after the transfer to improve performance over slow communications lines.

HANDLING OF DIRECTORY ARGUMENTS.  Default: For each pname that specifies a directory element, update downloads to the Attache workspace the contents of that directory, but not the contents of any of its subdirectories.

-r·ecurse

Includes files from the entire subtree below any subdirectory included in the top-level listing. Directories are created as necessary and the current directory is taken into account if relative patterns are given.

SPECIFYING A FILE TRANSFER LOG.  Default: None.

-log pname

Specifies a log file for the operation. The log file lists the workspace-relative pathname of each file transferred by the Attache update command, as well as an indication of any errors that occur during the operation. Log file pathnames are absolute, not relative to the current workspace root.

The log file can be used as an indirect file in a get command if there are errors which prevent the updating of all files.

EXAMPLES

The UNIX 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 shell or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.

ClearCase and ClearCase LT

NOTE: In the UNIX examples that follow, arguments and output that show multicomponent VOB tags are not applicable to ClearCase LT, which recognizes only single-component VOB tags. In this manual, a multicomponent VOB tag is by convention a two-component VOB tag of the form /vobs/vob-tag-leaf-for example, /vobs/src. A single-component VOB tag consists of a leaf only-for example, /src. In all other respects, the examples are valid for ClearCase LT.

• Preview an update of the view darren_3.2 and produce a log file in the C:\temp directory.

cmd-context update -print -log C:\temp E:\views\darren_3.2

• Update the file ./foo.c using the current time as the time stamp.

cmd-context update -ctime foo.c

• Update the current directory; if there are any hijacked files, rename them filename.keep and copy the VOB versions specified by the config spec into the view.

cmd-context update -rename

• Load into the current view the new elements in .\vobs\doc\user_manual, adding the rule load \vobs\doc\user_manual to the view's config spec.

cmd-context update -add_loadrules \vobs\doc\user_manual

Attache

• Determine which files have been changed since yesterday in the /vobs/proj VOB.

cmd-context update -print -since yesterday -r /vobs/proj

• Update all files changed since yesterday in the \proj_vob VOB, overwriting any writable files in the workspace.

cmd-context update -since yesterday -r -overwrite \proj_vob

• Download all files specified by the c:\users\jed\proj.ws project config file.

cmd-context update -all -r @c:\users\jed\proj.ws

• Update any files changed since the last update using the c:\users\jed\proj.ws project config file, logging results to the c:\users\jed\proj.log file.

cmd-context update -r -log c:\users\jed\proj.log @c:\users\jed\proj.ws

SEE ALSO

checkin, checkout, clearviewupdate, config_spec, edcs, get, findmerge, ln, merge, mkdir, mkelem, mv, rmname, setcs, uncheckout