Сравнение SVN с другими системами контроля версий

svnПоследнее время, появилось множество фанатов, орущих про то, что  — полный отстой, а Git/Mercurial — активно рулят. При этом, несмотря на плюсы распределённых систем, у них ещё много минусов, которые решаются или костылями, или инструкциями по работе, или надеванием штанов через голову, потому что «это модно».

Собственно, буду сравнивать концепцию DVCS (без сильных завязок на Git или Mercurial) и SVN, как одного из самых ярких представителей централизованных систем (TFS тоже яркий, но это комбайн с кучей бантиков и практически только под Visual Studio)

Всё нижеперечисленное, моё личное мнение, которое может не совпадать с мнением фанатов какой-либо системы, да и вообще быть ошибочным.

Начнём с плюсов DVCS:

  • У каждого своя пользователя копия репозитория в которой он может делать всё что угодно, до заливки в основной репозиторий
  • Удобные бранчи и теги
  • Более приличный мёрж (за счёт ченджсетов)
  • Отличная автономность
  • Возможность устраивать сложную систему иерархий в организации проекта
А теперь, про недостатки, про то, что не пишут или что обходится административными мерами:
  • Один репозиторий — один проект. Т.е. распределённые системы удобны для работы над одним проектом, и очень плохо разделять зону ответственности между связанными проектами. Технически, два независимых проекта, это два полностью независимых проекта, с разными репозиториями и отсутствием общей инфраструктуры
  • Подключение к проекту внешних модулей (например, общей между разными проектами, библиотеки). В svn это весьма коряво решается через svn:externals, и в git и в mercurial есть ещё более корявые решения, но в принципе решить задачу можно, хоть и очень коряво.
  • Проблема с хранением больших бинарных файлов (особенно, если они ещё и изменяются периодически). Т.к. у каждого разработчика по копии своего репозитория, то у каждого по копии всех этих файлов (и всей истории), даже если они ему и не нужны. Решение — использовать всяческие расширения или выносить эти файлы из DVCS в другие системы (например, тот же SVN).
  • Невозможность забрать всего-лишь несколько файлов из проекта. Например, менеджерам абсолютно не нужен код, им нужно только ТЗ, макеты и прочая мелочёвка. При этом, уровень грамотности у них в плане работы с VCS значительно ниже. В общем, как результат, проще документацию хранить отдельно, чем обучать менеджеров работе с DVCS.
  • Отсутствие единой сквозной нумерации. Прощай автоверсионирование в билдах и удобная привязка к багтрекеру. Проблема некритичная, но очень «радует» своим удобством.
  • Отсутствие возможности тонкого разграничения прав, например, запретить писать некоторым пользователям в важные конфигурационные файлы, или же заблокировать от изменений часть проекта.
  • Отсутствие возможности блокировки файлов. Фича редкая, но когда нужна, тогда без неё плохо. Можно обойти административными мерами, но их любят нарушать.
  • Практически всегда необходимо выделять центральный репозиторий (хотя бы для автомтатических билдов), как результат, он выполняет роль сервера SVN, т.е. в принципе, всё сводится назад, к централизованной системе с более умными клиентами у разработчиков.
  • Хуки на определённые группы файлов, и вообще слежение за изменениями. Необходимо прилагать дополнительные усилия для слежки, то, что в SVN делается из коробки.
  • Потеря исходников автоматически означает потерю всего репозитория, т.е. включает в себя всю историю, уже удалённые файлы, даты, список пользователей, ветвления. Т.е. ценность данной информации гораздо выше, стоимость потери — тоже. А с учётом пункта об проблемах с разграничением прав, всё становится совсем плохо. А потерять один ноутбук разработчика гораздо проще чем данные с одного сервера, охраняемого злобным цербером администратором.
И как закономерный результат: отлично DVCS применимы для распределённойразработки (как и следует из их названия) и слабо применимы для локальной группы разработчиков, когда все преимущества распределённости теряются, а недостатки никуда не деваются.
При этом для одного разработчика, это всё совсем плохо применимо, все преимущества нивелируются практически полностью, а недостатки становятся просто обузой. Какой смысл одному разработчику делать на каждый чих по репозиторию? Или мучаться, запёхивая каждый чих именно в один репозиторий? Зачем ему понятие локального и удалённого репозитория? Это абсолютно лишний шаг в данном случае.

В-общем, мое мнение: DVCS нужно засунуть туда, куда они пришли, в распредённость, и не иметь проблем с ними, если не видно явного преимущества в данный момент. Ведь из SVN всегда можно сделать экспорт в другую систему, когда это понадобится. А вот обратно — уже никак, и от проблем DVCS уже никуда не получится деться.

Оригинал: http://force-net.com/2011/11/svn-vs-dvcs.html

Запись навигация

Top