SVN vs DVCS

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

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

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

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

• У каждого своя пользователя копия репозитория в которой он может делать всё что угодно, до заливки в основной репозиторий
• Удобные бранчи и теги 
• Более приличный мёрж (за счёт ченджсетов)
• Отличная автономность
• Возможность устраивать сложную систему иерархий в организации проекта

А теперь, про недостатки, про то, что не пишут или что обходится административными мерами:

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

И как закономерный результат: отлично DVCS применимы для распределённой разработки (как и следует из их названия) и слабо применимы для локальной группы разработчиков, когда все преимущества распределённости теряются, а недостатки никуда не деваются.

При этом для одного разработчика, это всё совсем плохо применимо, все преимущества нивелируются практически полностью, а недостатки становятся просто обузой. Какой смысл одному разработчику делать на каждый чих по репозиторию? Или мучаться, запёхивая каждый чих именно в один репозиторий? Зачем ему понятие локального и удалённого репозитория? Это абсолютно лишний шаг в данном случае.

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