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

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

3 голосов
/ 16 января 2009

Хотя ранее были заданы соответствующие вопросы, я хотел бы увидеть идею о том, как можно обеспечить взаимодействие между двумя системами управления исходным кодом (SCM). Например, мы могли бы рассмотреть любой SCM (Mercurial, Git, SVN, CVS, Perforce, ClearCase ...).

В основном мне интересно, можно ли использовать ClearCase вместе с SVN или Git / Mercurial.

Как я могу иметь удаленное дерево исходного кода, поддерживаемое ClearCase, которое также поддерживается другим SCM (кроме ClearCase)?

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

Любые (другие / связанные) примеры / опыт приветствуются. Спасибо!

PS: Это , а не о сбрасывании ClearCase (я бы с удовольствием это сделал), речь идет о одновременной работе с двумя элементами управления исходным кодом в одном дереве исходных текстов.

Ответы [ 6 ]

4 голосов
/ 16 января 2009

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

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

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

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

1 голос
/ 16 января 2009

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

Есть как минимум несколько разных решений, о которых я знаю:

  • универсальное решение для взаимодействия SCM, такое как быстрый импорт стандарт обмена, созданный в 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. Я не знаю пример для такого решения.
1 голос
/ 16 января 2009

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

1 голос
/ 16 января 2009

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

1 голос
/ 16 января 2009

одна вещь, которая приходит мне в голову: git-svn : «Она обеспечивает двунаправленный поток изменений между Subversion и хранилищем git».

0 голосов
/ 16 января 2009

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

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

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

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

...