Как может быть достигнуто взаимодействие управления исходным кодом?

Я действительно не рекомендую смешивать их. Управление одним SCM - достаточно сложная задача, и вы не хотите, чтобы обычному пользователю приходилось иметь дело с несколькими из них.

Если вы все еще хотите смешивать, распределенные SCM, такие как Mercurial или git, имеют что-то приятное, а именно возможность использовать их, не навязывая их никому. Каждый разработчик / команда может управлять своей локальной копией / локальным филиалом в git или mercurial, и никто об этом не знает.

У git + subversion или mercurial + subversion есть то преимущество, что возврат в главный репозиторий является частью инструмента, но можно жить и без него.

В вашем случае похоже, что вам навязывают ClearCase, но вы хотите использовать альтернативу. Вы можете решить использовать git в своей команде и регулярно отправлять основную ветку в ClearCase.

мне на ум приходит git-svn: "Он обеспечивает двунаправленный поток изменений между Subversion и репозиторием git ".

Пока вы можете заставить других SCM игнорировать друг друга (через файл типа _1 _ / _ 2_) или заставлять их сотрудничать (например, git svn), я не понимаю, почему вы не должны этого делать. Я уже делаю через svn / Hg / git и CVS.

В очень общем виде вы всегда можете зафиксировать текущую HEAD «чужого» (ClearCase в вашем случае) репо в ветку git, перенастроить свою собственную ветку поверх этого и зафиксировать результат обратно во «чужое» репо. Вспенить, промыть, повторить.

Проблема с взаимодействием между двумя системами управления исходным кодом (SCM) заключается в том, что одна SCM имеет более богатую модель, чем другая (например, Subversion до 1.5.0 не хранила всех родителей слияния, если вы не использовали svnmerge или SVK, в то время как большинство современных SCM помнят слияния; Mercurial не поддерживает слияния осьминога, т. е. слияния с более чем двумя родителями).

Я знаю по крайней мере несколько различных решений:

• общее решение для взаимодействия SCM, такое как стандарт обмена fast-import, созданный в Git, но поддерживаемый Bazaar и, я думаю, также Mercurial, или такие инструменты, как Tailor (но у Tailor есть свои ограничения)
• конкретные инструменты, которые используют SCM API или SCM-скрипты, такие как git-svn между Git и Subversion (использует Subversion Perl API) или git-p4 между Git и Perforce
• вручную, то есть с использованием общей рабочей области (рабочего каталога), получение изменений (извлечение) из одного SCM и добавление изменений (завершение) в другой SCM. Это потребует настройки соответствующих файлов игнорирования, чтобы один SCM игнорировал другие вспомогательные файлы и каталоги SCM.
• эмуляция сервера в случае взаимодействия между централизованным SCM (например, CVS) и другим SCM (например, Git) путем эмуляции сервера для централизованного SCM, но при наличии репозитория в другом SCM, например git-svnserver
• бэкэнд данных, где один SCM (например, Bazaar или Darcs) хранит изменения (данные) в репозитории в другом формате SCM. Я не знаю примера такого решения.

Я согласен с BlueBird75: смешивание двух разных ссылочных данных не является хорошей идеей, по той же причине не рекомендуется иметь несколько баз данных с одинаковой информацией. В таких случаях нелегко управлять синхронизацией и дублированием.

Мы «публикуем» некоторые данные, управляемые в наших репозиториях ClearCase (VOB), в другие VCS (Subversion, Perforce, ...) или репозитории (например, Maven) для других команд, которые не используют ClearCase. Однако экспортируемые данные - это только доставки.

«Единица доставки» - это небольшой («маленький», как можно меньшее количество файлов) набор упакованных файлов: jar, war и ear - все это примеры таких упакованных файлов, но мы также включаем источники (сжатые в zip-файл), javadoc (также сжатый), сценарий для выполнения этой доставки и т. д.

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