[prog.flame] Я не расхваливаю Svn, просто...

...мне не нравятся две вещи: необъективность (особенно проистекающая из незнания) и приверженность моде.

Когда кто-то говорит, что "svn говно" или "ни за что не пойду в контору, где используют svn", то очень хочется выяснить степень владения говорящим обсуждаемого инструмента. Поскольку довелось видеть случаи, когда:

• люди не знали, что в svn можно создавать ветки и что структура из tags/trunk/branches -- это всего лишь рекомендация, а не захардкоженная намертво структура репозитория;
• люди не знали, что можно сделать checkout только небольшой части какой-либо конкретной ветки, а не всю ветку целиком. Не говоря уже про то, что из репозитория можно взять что-то по номеру конкретной ревизии;
• люди не знали, что коммитить можно только отдельные изменения, а не всю рабочую копию целиком;
• люди не знали, что есть команда svn mv. Поэтому при необходимости переименовать файл/каталог сначала вручную вызывали svn cp, затем svn rm (Upd. Вспомнился совсем уж клинический случай: человек делал сначала svn add файла с новым именем, но со старым содержимым, потом уже делал svn rm старого файла. При последующем мержинге все это вылезало боком, естественно);
• люди не использовали svn merge, а вместо этого строили diff-ы, а потом накатывали патчи в основную ветку. И даже не через patch, а вручную. Просто потому, что svn merge, как им доподлинно известно, убогий и глючный;
• люди не знали, как откатить изменения (т.е. никогда не слышали про обратный merge);
• люди не знали про svn:externals и при необходимости задействовать куски кода из других проектов тупо импортировали их в свой репозиторий, правили локально, а потом жаловались на сложности возврата правок и разъезжание версий сторонних компонентов;
• не говоря уже про то, что для многих Svn отождествлялся с TortoiseSVN и о наличии command-line интерфейса у svn знали далеко не все.

И это только то, с чем я сам столкнулся и чему приходилось учить. Если покопаться в архивах профильных форумов, там еще и не то можно найти. Причем все это пришлось на годы, когда у Svn особых альтернатив-то и не было. Что уже говорить про сейчас, когда более-менее полное представление об Svn имеют очень не многие.

Так что в случае критики Svn очень хочется сперва выяснить уровень компетентности говорящего. Редко это возможно, но зачастую проскакивают какие-то мелочи, которые заставляют усомниться в знании предмета.

Является ли Svn самой лучшей системой VCS? И лучше ли Svn чем Git?

Определенно, Svn самой лучшей VCS не является. Одно то, что за все это время разработчики Svn не смогли представить svn mv одной внутренней командной, а потому операция слияния не проходит так гладко, как в других VCS, говорит о многом.

Собственно, уже одно это может служить индикатором, что VCS с более грамотным подходом к мержингу предпочтительнее, чем Svn. Особенно в случаях, когда:

• наличие единого сервера недопустимо;
• нет необходимости хранить под контролем версий большие бинарные файлы;
• нет необходимости раздавать права доступа к различным частям репозитория.

Во всех этих случаях Git или Mercurial, или Darcs, или еще что-нибудь, будет однозначно удобнее Svn.

Другое дело, что три перечисленных выше фактора могут иметь место. И не просто так, а по вполне себе разумным причинам:

• единый сервер -- это простота архивирования репозиториев (особенно для больших проектов, с большим количеством работающих над проектом сотрудников);
• чекауты только части репозитория -- это повышение удобства работы с очень большими и старыми репозиториями (размеры которых исчисляются гигабайтами или десятками гигабайт);
• права доступа -- это защита интеллектуальной собственности, плюс наличие следов доступа к репозиторию, что бывает важно, когда возникают подозрения о краже этой самой собственности;
• бинарники под контролем версий -- это удобно в случаях, когда бинарники представляют из себя нужные приложению ресурсы (аудио, видео, изображения, сертификаты и т.д.), либо же являются архивами с исходниками сторонних компонентов.

Легко допускаю, что для подавляющего большинства все вышеперечисленные причины -- это ни о чем, ни с чем подобным сталкиваться не приходилось. Или же решалось какими-то другими средствами. Например, кто-то может считать git submodules удобнее, чем svn:externals... ;)

Ну так здесь то же самое, что и, скажем, с производителями тяжелых карьерных самосвалов. Подавляющему большинству перевозчиков, использующих грузовые автомобили, карьерные самосвалы не нужны. Что вовсе не означает ненужность такой техники вообще.

PS. Да, и про приверженность моде. Пусть простят меня фанаты git-а, но мне кажется, что нынешнее увлечение git-ом -- это именно мода. Впрочем, если я ошибаюсь на этот счет, то это совсем не страшно ;)