Можем ли мы наконец перейти к DVCS в корпоративном программном обеспечении? SVN по-прежнему необходимо для развития?
Git/Mercurial становятся все более и более популярными. Я видел множество статей, сравнивающих SVN с Git/Mercurial, но мне интересно, есть ли на самом деле какая-либо причина по-прежнему использовать SVN. Похоже, сейчас есть множество инструментов для Git/Mercurial, которые должны помочь распространить его корпоративное внедрение.
Есть ли причины по-прежнему использовать SVN? Mercurial/Git наконец готов для корпоративного принятия?
11 ответов
С одной стороны, интеграция SVN (с IDE, фреймворками, вики, ...) очень зрелая, а также с ее GUI и браузерами кода (хотя DVCS, такие как Git и Mercurial, прогрессируют каждый день).
С другой стороны, внедрение DVCS в корпоративной среде все еще не является тривиальной задачей:
- Некоторые требования нелегко выполнить (с точки зрения безопасности и контроля доступа, администрирования и ограничения доступа)
- Парадигма DVCS более сложна для понимания, с множеством плюсов и минусов.
- Вам действительно нужно использовать множество рабочих процессов, а не полагаться на централизованный SVN.
- Переход с CVCS на DVCS затруднен
Просто чтобы быть ясно, использование DVCS может быть очень правильным выбором:
- для нового проекта, где разработчики не связаны с устаревшими инструментами или процессами
- особенно когда разработчики географически не расположены в одном и том же месте (часто в случае разработки с открытым исходным кодом, именно поэтому DVCS в основном используются там).
Stackru (не проект с открытым исходным кодом) использует Mercurial (см. HgInit, написанный Джоэлем Спольски).
Они мигрировали из SVN в DVCS:
- отчасти потому, что их разработчики сейчас во всем мире (!)
а также потому, что средства слияния DVCS намного более продвинуты, чем в SVN.
(что им нужно для поддержки множества параллельных, немного отличающихся версий своего кода, между сайтами SO, сайтами StackExchange V1 и V2, Area 51, ...)
См. " Различия между DVCS и CVCS" или " Каковы преимущества Mercurial или git перед svn для ветвления / слияния?".Для корпоративной среды (где я нахожусь) любой переход любого рода не тривиален, потому что это должно быть:
- финансируется (деньги, даже если инструменты бесплатны)
- поддерживается (это означает наличие нужных людей с правильными компетенциями)
- интегрированный (с существующими устаревшими инструментами, графическими интерфейсами, IDE, такими как Visual Studio или многими другими, ...)
- администрируемый (с точки зрения общих серверов, даже для DVCS)
- задокументировано (особенно для пользователей, пришедших с CVCS, например SVN)
Поэтому DVCS также может быть очень полезным в корпоративной среде:
(См. " Уровень внедрения Git на корпоративном уровне?" Или " Контроль источников на основе Git на предприятии: предлагаемые инструменты и практики?".)
Он (даже для новых проектов) просто не так легко внедрить, как в меньшей структуре или в средах с открытым исходным кодом.
Считается ли это лучше для одного разработчика?
Во всяком случае, Subversion хуже для одного разработчика (сложнее в настройке).
Но хорошей причиной продолжать использовать SVN является инерция. Если SVN хорошо работает для вашего проекта (или в вашей компании), нет необходимости проходить через трудности переключения. Могут быть затраты на обучение, связанные с обучением всех новым инструментам (и новым рабочим процессам), без реальных преимуществ.
Я думаю, что Subversion по-прежнему работает лучше, чем Mercurial и Git для больших файлов, таких как медиаресурсы, файлы Photoshop, композиты After Effects и т. Д. Я помню, как Линус Торвальдс упоминал большие файлы как одну из немногих потенциальных проблем с Git в этом Google Tech Talk. В Mercurial есть несколько расширений для хранения больших файлов вне хранилища. Таким образом, кажется, что они оба страдают от некоторого снижения производительности и / или других проблем в этом сценарии.
Subversion, с другой стороны, используется текущим проектом Blender Open Movie. Я не думаю, что они используют его для хранения визуализированных кадров, так как это будет по крайней мере несколько гигабайт данных для каждого прохода рендеринга. Но, тем не менее, со всеми трехмерными сценами, объектами, оснастками, текстурами и сценариями, это все еще один большой репозиторий со множеством больших файлов.
Я вижу причины, по которым вы могли бы продолжать использовать SVN, если использовали его в течение длительного времени. Особенно в небольшой компании или в кругу программистов переход с SVN на git или Mercurial, когда вы можете не использовать какие-либо из их более мощных функций, может помешать вам переключиться. Как отмечает Тило, крупная компания, использующая SVN, найдет это изменение монументальным.
Кроме того, я думаю, что у SVN есть еще места, особенно когда речь идет о преподавании контроля версий. Но это основано на моем личном опыте изучения SVN в университете, а не на самоучении, поэтому мое мнение не будет объективным.
При этом, если вы запускаете репозиторий с нуля, я не могу придумать условия, при которых вы могли бы решить, что SVN абсолютно необходим. Возможно при работе с устаревшими системами.
или старые пользователи;)
Я не знаю каких-либо внутренних причин предпочитать централизованные vcs, есть много внешних факторов, таких как унаследованные системы, управленческая инерция, кривая обучения и т. Д.
DVCS в значительной степени демонстрирует себя как "лучшая мышеловка".
На самом деле вопрос не в SVN против Git/Mercurial, а в распределении и централизации. Централизация может быть лучше в некоторых ситуациях, например, в корпоративной среде, где требуется жесткий контроль и тщательное ведение журнала.
Мы используем Subversion в качестве хранилища для данных, что не является тривиальным слиянием (мы занимаемся разработкой оборудования, а файлы проекта представляют собой недокументированный двоичный формат). Преимущество SVN заключается в том, что вы можете устанавливать блокировки для файлов, так что только один разработчик может работать с файлом, а также вынужден проверять самый новый файл перед редактированием.
Subversion идеален, когда идеализирована централизованная парадигма.
Одна из таких ситуаций - при работе с бумагами. Гораздо больше смысла хранить только одну мастер-копию, из которой все тянут. Мы не хотим создавать ветви или теги. Мы просто хотим отслеживать, кто вносит изменения, а затем распространять их среди всех авторов.
Вы можете использовать как Git, так и Hg в качестве клиентов SVN. Это означает, что вы можете иметь лучшее из обоих миров.
Однако вы не можете использовать SVN в качестве клиента для Git или Hg.
Во многих отношениях идеальный случай - это центральный репозиторий SVN, в котором пользователи используют в качестве клиента любой DVCS.
SVN намного легче изучать и использовать для многих людей, а его инструментарий гораздо более зрелый.
Мой ответ основан на нескольких предположениях:
- Предмет, который вы храните в системе контроля версий, - это исходный код, а то, что вы делаете с кодом, - это профессиональная разработка программного обеспечения.
- Вы всегда должны использовать лучший инструмент для работы; Как говорит тест Джоэла, вы должны использовать лучшие инструменты, которые можно купить за деньги, даже если они бесплатны.
- Внешние факторы не имеют отношения к выбору наилучшего инструмента для работы - это препятствия, которые вы должны преодолеть для принятия. В то же время эти причины являются оправданием для продолжения использования Subversion, а не причинами, по которым вам следует явно его использовать.
Во-вторых, DVCS считается лучшим, более мощным инструментом, чем Subversion. В прошлом много говорилось о переполнении стека, и другие ответы подсказывали, что большинство людей согласны с тем, что DVCS - "лучшая мышеловка". Я не считаю необходимым доказывать это; Вы можете просмотреть связанные / похожие вопросы, уже размещенные здесь. Конечно, не каждый DVCS будет лучше, чем Subversion во всех аспектах, но я считаю, что ведущие DVCS, такие как Mercurial, git и т. Д., Лучше, чем Subversion, почти во всех аспектах.
Таким образом, по моей логике, если вы собираетесь выбрать лучший инструмент для работы, а Subversion является худшим инструментом, Subversion больше не следует использовать. Это не означает, что мы увидим мгновенное всемирное принятие, но я утверждаю, что - если вы верите в использование лучшего инструмента для работы - все организации должны планировать переход на DVCS. Конечно, многие не будут, и я ожидаю, что люди будут продолжать использовать Subversion в течение длительного времени.