Самый известный метод замены динамических представлений ClearCase в GIT

Question

Мы переходим в GIT от CleaCase UCM 8.0.1.3. У нас есть несколько проектов, которые используют динамические представления. и я хотел бы знать, если есть некоторые наиболее известные методы и использовать случаи миграции использования динамических представлений в GIT.

Простейшие проекты, просто используя один динамический вид, и вся команда пишет на одно и то же место. Он содержит только документацию, и им нужна способность немедленно знать, кто касается файла. Это всего лишь один поток для всех. Преобразование этого в GIT является простым. Просто создайте репозиторий в глобальном сетевом пути. Любые другие идеи?

Комплексные, следующие. Допустим, у меня есть два компонента: глобальный, специфический. «Конкретный» - это обычный снимок для каждого разработчика. «Глобальный» находится в динамическом представлении, и любое изменение в нем позволяет конкретному использовать изменения, сделанные в Глобальном, немедленно.

При добавлении к этому вопросу разрешений, только определенным людям разрешено вносить изменения в глобальный компонент.

И еще, существует автоматический механизм, который запускается на определенном компьютере, который автоматически изменяет глобальный компонент путем импорта из другого стороннего приложения.

И, наконец, существует механизм авторизации для каждой папки в части моментального снимка для определенных людей в определенной папке. Это еще одна проблема, я добавил ее в качестве справочной информации.

Итак, вопрос в том, какие идеи, как управлять им самым простым способом? push/pull hooks - это решение, которое мы сейчас исследуем. есть ли более приятное решение?

Answer 1

Просто создайте хранилище в глобальной сети пути

Это кажется наиболее прямым способом извлечь выгоду из общего доступа, предоставленного ClearCase динамических представлений.

При добавлении к этому вопросу разрешения разрешается вносить только определенные люди в глобальный компонент.

Это должно управляться с помощью ACL (Layer Access Control), как gitolite.

«Global» один находится в динамическом представлении и любые изменения в нем делает Specific один, чтобы использовать изменение сделано в Global, немедленно.

Это звучит как:

• Global должен быть объявлен как подмодуль Specific
• подмодуль должен быть настроен на follow a branch

Таким образом, любой git submodule update --remote обновит Global является любые новые коммиты были выдвинуты.

Если ваша служба репо-хостинга предоставляет webhooks (like gitHub does), то каждый клиент может иметь прослушиватель для события push и запускать обновление подмодуля.
Даже если у частного хостинга нет веб-узлов, вы можете реализовать его с помощью крючка после приема (generating the JSON payload для отправки зарегистрированным клиентам-слушателям).