Mercurial для проектов ОС и SVN для корпоративных проектов?

Question

поправьте меня, если я не прав, но разве не распределенные SCM для проектов ОС, в то время как централизованные SCM лучше для корпоративных / частных проектов?

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

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

Answer 1

Вы можете использовать DVCS (например, Mercurial) в крупной корпорации .

Пределы DVCS по сравнению с VCS по существу:

• размер (вы не можете бесконечно хранить все в DVCS, то есть вы должны переосмыслить свои данные разработки как модули вместо монолитного набора файлов , который может еще можно найти в крупных проектах)
• правильное управление доступом : в DVCS это не так детально, как в VCS, в основном потому, что многие внешние стороны могут внести свой вклад в проект с различными схемами аутентификации пользователей. Владение сложнее в управлении.
• рабочий процесс : рабочий процесс DVCS является более сложным, даже если он может эмулировать один из CVCS (один центральный репозиторий, действующий в качестве эталона для всех остальных)

Тем не менее, DVCS позволяет по-новому публиковать (pull / pull) данные, которые могут помочь межгрупповым «предварительным поставкам» (когда команда хочет поделиться разработкой, даже если есть все еще находятся в стадии разработки и еще официально не переданы в центральное хранилище): вы становитесь пассивным производителем и активным потребителем .

---

Томислав Накич-Альфиревич просит в комментариях:

Не могли бы вы проиллюстрировать свой второй пункт, сравнивая DVC с централизованным?

Правильное управление доступом сложно, особенно если крупная корпорация:

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

В этих случаях это означает:

• аутентификацию пользователя не всегда легко согласовать (один и тот же пользователь может иметь разные идентификационные данные в зависимости от того, где он / она клонирует репозиторий). Можно настроить аутентификацию на основе SSH (gitosis, gitauth ).
• метаданные, связанные с файлом, ограничены, например, Git-тегами
  (группа файла, например, может не существовать на данном компьютере, где клонировано хранилище)
  (метаданные из других инструментов не поддерживаются прозрачно )
  ( специальные символы в именах файлов могут быть проблематичными )
• права доступа часто ограничены всем репозиторием и не изначально управляются для ветви или для файла (для этого должен быть настроен сервер, такой как gitolite для Git, в отличие от CVS, у которого всегда есть сервер, что означает, что он будет более склонен предлагать более детальный ACL)

Например, Git немного слишком просто , чтобы напрямую ответить на вопросы крупных корпораций:

Люди, плохо знакомые с git (то есть я предлагал такие улучшения, когда тоже начинали;)) часто говорят о добавлении этой функции или этой функции, даже не осознавая, что git действительно очень и очень прост.
Он имеет файлы, каталоги, коммиты, теги и вот и все .
Его власть над централизованными решениями заключается в отсутствии суррогатных идентификаторов, таких как путь филиала, порядковый номер, присвоенный серверу и т. д.

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

Answer 2

Нет, определенно нет. Это предположение о том, что DVCS не будут подходить для предприятия, является неверным, распространенным аргументом FUD людей, которые по какой-либо причине хотят не отказываться от SVN.

На самом деле, также в корпоративных настройках DVCS дает вам много преимуществ:

• Возможность часто регистрироваться, не рискуя блокировать других людей
• В автономном режиме
• Высокая производительность
• Эффективное ветвление / слияние
• Схема доступа по запросу

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

Привязка к обсуждению в ответе выше; таким образом, DVCS предоставляют вам больше контроля над вашим репозиторием, в то время как в SVN обычно единственная реальная работоспособная модель - предоставить всем вкладчикам доступ по крайней мере к частям кода.

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

Часто вам нужно не изучать практики, которые вы изучили с помощью централизованных VCS, вернуться к сценариям использования и тому, что вы хотите сделать, а затем подумать, как DVCS может расширить это.

Очень хорошая статья для изучения различий между системами контроля версий: Смысл систем контроля версий .