подвижный для проектов ОС и svn для проектов Предприятия?
исправьте меня, если я неправ, но не распределяюсь SCMs для проектов ОС, в то время как централизовано, SCMs лучше для корпоративных/частных проектов?
причина с, например, подвижный любой получает точную копию репозитория с ПОЛНЫМИ функциями истории, в то время как с централизованным Вы только получаете последнюю рабочую копию.
Я более фокусируюсь на частных проектах, таким образом, я задаюсь вопросом, не имеет ли лучше с централизованным SCMs или разве это значения?
2 ответа
Вы можете использовать DVCS (например, mercurial) в большой корпорации.
Ограничения DVCS по сравнению с VCS следующие:
- размер (вы не можете бесконечно хранить все в DVCS, что означает, что вы должны переосмыслить ваши данные разработки как модули вместо монолитного набора файлов, который все еще можно найти в больших проектах)
- управление правом доступа: оно не такое тонкое в DVCS, как может быть в VCS, в основном потому, что многие внешние стороны могут вносить вклад в проект, с различными схемами аутентификации пользователей. Управлять правом собственности сложнее.
- рабочий процесс: рабочий процесс DVCS более сложен, даже если он может имитировать рабочий процесс CVCS (одно центральное хранилище действует как ссылка для всех остальных)
Тем не менее, DVCS позволяет новый способ публикации (pull/pull) данных, что может помочь при "предварительных поставках" между командами (когда команда хочет поделиться разработками, даже если они еще находятся в процессе и еще официально не зафиксированы в центральном хранилище): вы становитесь пассивным производителем и активным потребителем.
Tomislav Nakic-Alfirevic спрашивает в комментариях:
Не могли бы вы проиллюстрировать ваш второй пункт, сравнивая DVC с централизованным?
Правильное управление доступом - более сложная задача, особенно если крупная корпорация:
- вынуждена делиться некоторыми своими репозиториями с внешним предприятием для совместной аутсорсинговой разработки
- позволяет клонировать некоторые из своих репозиториев на персональном компьютере (при работе в мобильной среде на другом объекте, где разработчик не всегда имеет доступ к сети предприятия)
В таких случаях это означает:
- аутентификацию пользователя не всегда легко согласовать (один и тот же пользователь может иметь разные идентификаторы в зависимости от того, где он клонирует репозиторий). Можно настроить аутентификацию на основе SSH (gitosis, gitauth).
- метаданные, связанные с файлом, ограничены, например, через Git-теги
(группа файла, например, может не существовать на данном компьютере, где клонируется репозиторий)
. (метаданные из других инструментов прозрачно не поддерживаются)
(специальные символы в именах файлов могут быть проблематичными) - права доступа часто ограничены всем репозиторием и не нативно управляются по веткам или файлам (для этого должен быть настроен сервер типа gitolite для Git, в отличие от CVS, у которого всегда есть сервер, что означает, что он будет более склонен предлагать более тонкие ACL)
Git, например, немного слишком прост для прямого ответа на проблемы больших корпораций:
Люди, только начинающие работать с git (то есть, я тоже предлагал подобные улучшения, когда начинал ;)), часто говорят о добавлении этой или той функции, не понимая, что git действительно очень очень прост.
В нем есть файлы, каталоги, коммиты, теги и все.
Его преимущество перед централизованными решениями заключается в отсутствии суррогатных идентификаторов, таких как путь ветвления, присвоенный сервером порядковый номер и т.д.Да, может быть больше отношений и метаданных для представления множества вещей.
История и объединение файлов, переименование каталогов, выборка, возврат.
Но все это усложняет базовую модель, которая уже показала свою способность справляться с этими вещами - с оговорками.
Но вознаграждение - простота - вполне стоит этих оговорок.
Нет, определенно нет. Это предположение о том, что DVCSes не подходят для предприятия, в значительной степени ложно, это распространенный аргумент FUD от людей, которые по какой-либо причине имеют желание не отказываться от SVN.
На самом деле, DVCS также в корпоративных настройках дает вам много преимуществ:
- Возможность часто проверять, не рискуя блокировать других людей
- Автономная работа
- Высокая производительность
- Эффективное ветвление / слияние
- Извлечение шаблон доступа
Что касается последнего, вы можете предоставить опытным разработчикам прямой push-доступ к основному репозиторию, в то время как для новых или младших участников их наставник извлекает из них и просматривает их изменения, прежде чем отправлять их.
Привязка к обсуждению в ответе выше; Таким образом, DVCS дает вам больше контроля над вашим репозиторием, в то время как с SVN, как правило, единственной реальной работоспособной моделью является предоставление всем участникам доступа к фиксации хотя бы к частям кода.
У вас может быть менее детальный контроль над разрешениями для разделов с кодом, однако вы можете предоставить различным группам (например, группе документации) их собственный клон основного репозитория и периодически объединять его обратно после проверки. Или поместите документацию в совершенно другой репозиторий.
Часто вам нужно отучиться от практики, которую вы изучили с централизованными VCS, вернуться к вариантам использования и тому, что вы хотите делать, а затем подумать, как DVCS может расширить возможности этого.
Очень хорошая статья для ознакомления с различиями между системами контроля версий - это Осмысление систем контроля версий .