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