Yes: script the ClearCase view creation or explain them the mkview usage. Each user can then create is own view.

创建视图绝对不是配置管理器的角色。

Create views is definitely not the role of a configuration manager.

1 / 确定视图命名约定

• username_view目的：非UCM动态视图


• username_view目的_snap：非UCM快照视图


• username_streamname：UCM动态视图


• username_streamname_snap：UCM快照视图

• username_viewPurpose: non-UCM dynamic view
• username_viewPurpose_snap: non-UCM snapshot view
• username_streamname: UCM dynamic view
• username_streamname_snap: UCM snapshot view

我建议使用全小写的视图名称。

I would recommend all-minuscule case for the view names.

我真的建议始终使用视图名称中包含用户名（作为前缀）。当您知道谁拥有视图而不必 ct lsview时，管理/管理非常容易。

I really recommend always having the username included (as a prefix) in the name of a view. It is so much easy to manage/administer when you know who own the view without having to "ct lsview' it.

2 / 确定视图存储约定

• 一个具有通用存储名称的中间视图存储或一个通用UNC路径


• 或每个开发人员桌面上的一个视图存储。

我使用第二个约定，因为我认为它们的视图是他们可以根据需要创建/删除/重新创建。

I use the second convention, because I consider their view as transient spaces for them to create / delete / recreate as they need.

3 / 赋予用户权限

• 制作一个脚本（类似于乔纳森的脚本，但有更多选择，并且能够在Windows或Unix上运行）


• 描述mkview Wiki页面中的命令

我实际上使用第二种约定，因为每个用户都可以轻松键入mkview并考虑到他/她的环境详细信息（Windows / Unix，中间存储/本地存储等）

I actually use the second convention, because each user can quite easily type a mkview and take into account his/her environment details (Windows/Unix, central storage/local storage, ...)

所以需要教他们如何配置他们的配置规范（即使在UCM中），以便：

You also need to teach them how configure their config spec (even in UCM), in order to:

• 不选择丢失+找到目录（在UCM中合并时很有用）


• 不选择以前的配置规范规则尚未选择的任何内容，这意味着在需要时添加'element / aVob / * -none' （在快照视图中有用，以便没有很多空目录）

• not select "lost+found" directories (useful when merging in UCM)
• not select anything not already selected by previous config spec rules, meaning adding if needed a 'element /aVob/* -none' (useful in snapshot view in order to not have many empty directories)