Да: сценарий создания представления ClearCase или объяснение им использования mkview. Каждый пользователь может затем создать собственный вид.
Создание представлений определенно не является ролью менеджера конфигурации.
1 / Определение соглашения об именах представлений
- username_viewPurpose: динамическое представление не-UCM
- username_viewPurpose_snap: представление снимка без UCM
- username_streamname: динамическое представление UCM
- username_streamname_snap: представление снимка UCM
Я бы порекомендовал все-крошечный регистр для имен представлений.
Я действительно рекомендую всегда включать имя пользователя (в качестве префикса) в имя представления. Управлять / администрировать так легко, когда вы знаете, кому принадлежит представление, без необходимости его "ct lsview".
2 / Определение соглашения о хранении представления
- либо одно централизованное хранилище с общим именем хранилища, либо общий UNC-путь
- или один просмотр хранилища на рабочий стол разработчика.
Я использую второе соглашение, потому что я рассматриваю их вид как временные пространства для их создания / удаления / воссоздания по мере необходимости.
3 / "уполномочить" пользователя
- Создайте сценарий (как у Джонатана, но с чуть большим количеством опций и способный работать для Windows или Unix)
- Опишите команду mkview на вики-странице
Я на самом деле использую второе соглашение, потому что каждый пользователь может довольно легко набрать mkview и принять во внимание детали его / ее среды (Windows / Unix, центральное хранилище / локальное хранилище, ...)
Вам также нужно научить их, как настраивать спецификацию конфигурации (даже в UCM), чтобы:
- не выбирать каталоги "lost + found" (полезно при объединении в UCM)
- не выбирать ничего, что еще не было выбрано в предыдущих правилах спецификации конфигурации, что означает добавление при необходимости
'element /aVob/* -none'
(полезно в режиме моментального снимка, чтобы не иметь много пустых каталогов)