Значение использования Git с помощью ClearCase, AccuRev или Perforce?

Меня интересует ценность (или отсутствие) использования традиционного продукта SCM (ClearCase, AccuRev, Perforce и т.д.) вместе с Git для крупных проектов с распределенными командами.

Есть ли существенная добавленная стоимость с точки зрения повышения прозрачности в деятельности команды? Контроль ветвления и слияния? Контроль доступа и безопасность? Выпуск техники? Другие факторы?

Или лучше ли Git само по себе? Или есть SCM с открытым исходным кодом, который будет эквивалентен упомянутым выше коммерческим продуктам?

Спасибо.

Ответы

Ответ 1

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

В большинстве проектов используется только один VCS (например, git или Subversion) и может делать все, что им нужно (разветвление,..), поэтому, если у вас нет требования, которое вы знаете, что необычно, вы можете быть уверены, что один продукт сделает все, что вам нужно.

Ответ 2

Интеграция Git с ClearCase или SVN не является тем, что я ищу на данный момент, главным образом потому, что репозиторий Git не может хранить одни и те же данные (двоичные файлы) или том (количество/размер файлов), чем традиционные централизованные репозитории.
См. "Каковы ограничения Git?.

Я пытаюсь представить Git прямо сейчас в корпоративной среде ClearCase-SVN в качестве автономной альтернативы.

В то время как скорость, личные коммиты и функции слияния очень ценятся, меня просят решить реальные проблемы в терминах:

  • централизация: центральные хранилища по-прежнему являются мандатами, чтобы служить в качестве ссылки для многих команд для синхронизации своего кода с
  • modularization: нет возможности создать только один VOB (ClearCase) или один репозиторий Subversion и начать все в нем: каждый репозиторий Git должен быть очень мелким, чтобы добавить когерентное значение при пометке или ветвлении (эти операции относятся ко всем Git репо, а не к подкаталогу в пределах указанного репо).
  • аутентификация: каждый пользователь ссылается в LDAP, и мне нужно придумать крючки prereceive, чтобы иметь хотя бы одну фиксацию с правильной конфигурацией user.name (т.е. user.name соответствует общему имени cn в LDAP нашей компании). (немного похож на gitolite script 'contrib/update.email-check', но для user.name, а не для электронной почты).
  • правильный доступ: gitolite - огромная помощь здесь, чтобы получить очень точный ACL для этих центральных репозиториев.
    Но использование закрытых/открытых ключей ssh ​​также означает наличие закрытых ключей с фразой (обязательно в соответствии с нашей командой безопасности), и это не является тривиальным для интеграции с Hudson или другими инструментами.

Короче говоря, я все еще нахожу Git лучше, но поскольку я отвечаю за реализацию его установки/администрирования, я полностью согласен с моим предыдущим анализом, сделанным в вопросе SO "Можем ли мы наконец перейти к DVCS в корпоративном программном обеспечении? Является ли SVN еще "обязательным" для разработки?";).

Ответ 3

Есть значение.

  • Используйте гибкость и удобство дешевого локального ветвления для облегчения потока работы разработчика в локальной (машинной) среде, используйте централизованную систему для легкого управления разрешениями на основе ролей и конгломерацией большого количества файлов.

  • Развертывание на основе задач на основе задач остается в распределенной системе и сохраняет централизованный очиститель истории.

  • Централизованные системы могут использоваться для выгрузки больших двоичных активов из распределенных систем.

Существует стоимость.

  • Поддержка/обучение для гибридной среды.

  • Требуется найти/поддерживать слой перевода между системами.