Administering platforms for HCL VersionVault

Learn how to perform HCL VersionVault administrative tasks on supported platforms. The term platform refers to a specific operating system that is running on a specific hardware architecture. In these topics, the term platform also includes Web browsers.

HCL VersionVault supports a variety of platforms used for software development. The term platform means a specific operating system that is running on a specific hardware architecture.

In these topics, the term platform also includes Web browsers.

Summary of platform-specific differences

Because HCL VersionVault is tightly integrated with the operating system, the behavior of certain of its features can vary somewhat across the range of supported platforms. In addition to this document, information about platform-related behavior can be found in the following documents:
  • Developing Software, which describes how to access VOBs and views across platform types and explains issues regarding case-sensitivity and naming when accessing objects in VOBs
  • VersionVault Guide to Building Software, which describes differences in writing make files for different platforms and compilers.
  • Reference pages in the VersionVault Command Reference, which describe platform-specific differences in commands, when there are any.
  • The Help, which contains detailed information about cross-platform file system access, line-terminator conventions in mixed environments, and the use of NAS devices with VersionVault.
The following table shows the most important differences between HCL VersionVault on Linux™ and HCL VersionVault on Windows™.
Table 1. Differences between HCL VersionVault on Windows™ and Linux™
Feature On Linux™ On Windows™
Starting dynamic views Use setview or startview. The setview command starts a new shell that uses a set of rules to select specified versions of files stored in a VOB. The startview command starts a process that is consulted when accessing files by means of a view-extended pathname to a VOB. HCL VersionVault Windows Explorer creates shortcuts to views that you own. In VersionVault Windows Explorer, start a view by clicking the icon for the view shortcut. A dynamic view that you have started is displayed as a folder below the dynamic-views drive (drive M by default), which is accessible through Windows™ Explorer or a command shell.

There is no equivalent to the cleartool setview command. However, clicking a view shortcut, mapping a drive letter to a view, or browsing for a view using My Network Places, are all comparable.
Accessing active dynamic views Access the views through the /view directory. Access all dynamic views active on the current computer from the dynamic-views drive (drive M by default), or map each active view to its own drive letter from VersionVault Windows Explorer by clicking the view shortcut.

Each active view tag also is displayed under the UNC name \\view\viewname.
Activating VOBs All users can mount all public VOBs. Private VOBs can be mounted only by the VOB owner or root. All users can mount all VOBs, public or private. Public VOBs are distinguished only by the fact that they can be mounted with the command cleartool mount -all.
Accessing mounted VOBs through dynamic views From a shell started with the setview command, access each VOB mounted on the current computer using the vob-tag path name.

When using the startview command, access VOBs through the pathname /view/view-tag/vob-tag.

 Access each VOB mounted on the current computer through a specific view tag. For example, M:\view-tag\vob-tag or D:\vob-tag.
Security model for modifying VOBs A VOB inherits the identity, primary group, and additional group list of the user who runs the mkvob command. When you create a VOB, it does not include the "additional group" list. Only the creator's UID and primary group are assigned ownership of the VOB.

Windows™ VOBs must be created by a user whose primary group is the same as the primary group of all other users who will be writing to the VOB. If any users are members of more than one group, the administrator must set the CLEARCASE_PRIMARY_GROUP environment variable to specify the primary group.

For more information, see the Help and the env_ccase reference page.
Symbolic links and hard links File systems support symbolic links and hard links. Windows™ file systems do not support symbolic links or hard links. Therefore, remote storage pools (mkpool –ln) and remote view-private storage (mkview –ln) are not supported on Windows™ VOBs and views. However, dynamic views do support VOB symbolic links and VOB hard links.
Wildcard characters

(See the wildcards_ccase reference page.)

 Standard command shells support wildcard characters (*, ?, and so on) on the command line. Because standard Windows™ command shells do not expand pathname wildcard characters (*, ?, and so on) on the command line, cleartool commands cannot include pathname wildcards unless the commands are issued in interactive mode, when cleartool itself processes the command line.
Case sensitivity File creation and file lookups are case-sensitive. File-creation operations typically preserve case, but file lookups are not case sensitive.

Note that cleartool is case-sensitive on Windows™.
Line termination Line termination sequences in most text editors are typically a single newline (NL) character or a line feed (LF) character. Line termination sequences in most text editors are typically a CR and LF sequence.

Note how the text editors that you use handle line termination. Information about line termination issues are discussed in the Help, and the msdostext_mode reference page.
The lock manager Does not run the lock manager process on Linux™. Database access for each VOB on a VOB server is now handled by the VOB's db_server process.

Other platform-specific differences

The following reference pages in the VersionVault Command Reference describe platform-specific differences in commands:
  • export_mvfs
  • exports_ccase
  • init_ccase
  • mount_ccase