Альтернативы с открытым исходным кодом для ClearCase

Question

возможно, мой вопрос не перефразирован правильно, поэтому позвольте мне попытаться объяснить это.

Я пытаюсь исследовать альтернативы ClearCase с открытым исходным кодом. Одна из его сильных сторон заключается в том, что он позволяет логически разделять контент на отдельные централизованные базы объектов версий (или vobs), к которым мы можем контролировать доступ. То есть репозиторий предоставляет унифицированное представление с административной точки зрения, и тогда мы можем назначить правила контроля доступа, которые ограничивают, кто может видеть / изменять то, что в репо.

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

Кто-нибудь, читавший это, имел какой-либо опыт настройки и использования системы управления версиями с открытым исходным кодом? В частности, что касается применения правил контроля доступа к подмножествам содержимого в хранилище (размером в терабайты)?

Те же вопросы в отношении централизованных альтернатив с открытым исходным кодом.

Будем весьма благодарны за любые опыты из первых рук и анекдоты из окопов.

Answer 1

DVCS обычно требует, чтобы у каждого разработчика была полная копия репозитория, чтобы они могли плохо подходить для такого большого набора данных.

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

Если в содержании есть логические подразделения, вы можете разделить их на отдельные меньшие репозитории. Git & Mercurial позволяет вам создавать подпозитории, которые могут упростить процесс.

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