Возможные дубликаты:
Почему git лучше, чем Subversion?
Я уже много читал (недостаточно, чтобы получить идеальную картину) о системах управления версиями, и очевидный вывод состоит в том, что git является просто лучшим. Может быть, Базар. Или Меркуриаль. Но если так было, то никто не будет использовать SVN, но они все равно это делают. Зачем? У меня нет собственного мнения о том, что v.c.s. как правило, лучше всего из-за отсутствия опыта с ними. Не могли бы вы поделиться своими мыслями?
В настоящее время я поддерживаю службу контроля версий для исследовательского учреждения США. Мы не только поддерживаем SVN в дополнение к Git и Mercurial, но также и CVS.
SVN "функция убийцы" среди наших пользователей - узкие клоны. Вы можете сделать проверку только одного подкаталога в глубине иерархии, загрузить только файлы, связанные с этим каталогом, и все еще иметь возможность совершать коммиты. Git совсем недавно дал аналогичную, но не совсем полезную вариацию этой функции, называемую разреженными кассами (см. также Редкая проверка в Git 1.7.0?). Это позволяет фильтровать ваше рабочее дерево, но все равно заставляет вас загружать всю историю всего проекта, что может быть непомерно высоким, даже если большие двоичные файлы не задействованы. Имейте в виду, что диск дешев, и если вы поглощаете удар начального клона заранее, последующие тяги достаточно быстры, но это не помогает людям, которые отправились в путешествие, прежде чем они поняли, что им нужно клонировать, и в любом случае даже Git редкие проверки не позволят вам запустить свое рабочее дерево на пять уровней вниз, поэтому он выглядит немного уродливым.
Кроме того, пользователи находят authz файлы легче писать, чем Git commit hooks, более удобны с синтаксисом и методологией SVN, чем любые DVCS, и, возможно, самое главное, уже имеют много тысяч транзакций история в SVN. Эксперименты по переносу больших репозиториев Subversion на Git или Mercurial дали смешанные результаты, и это ученые, пытающиеся получить работу над собственными проектами, не жертвуя своим временем на разработку DVCS.
CVS по-прежнему имеет следующие причины. Представьте, что пользователь Git имеет редкие проверки, которые также позволяют произвольно переназначить, где файлы в филиале отображаются в вашем рабочем дереве, используя формат, который версируется вместе с репозиторием и распространяется с каждым обычным нажатием, что позволяет записывать определения, в которых могут быть группы, которые могут включать другие группы, и которые только вытягивают файлы, необходимые для размещения файловой системы на клоне. Это прямое в модулях CVS и невозможно в каждом DVCS. Для всех грехов CVS (и поверьте мне, мы прекрасно их понимаем и уклоняемся от нашего пути, чтобы препятствовать новым проектам CVS, если они абсолютно не могут жить без модулей), невозможно убедить группу, использующую эту функцию для перехода на другую систему управления версиями.
Программное обеспечение DVCS принесло несколько потрясающих нововведений, но они также пропускают вещи, которые некоторые разработчики считают само собой разумеющимися. Убедитесь, что вы заранее знаете, каковы ваши требования, прежде чем выбирать.
Говоря о компании, над которой я работаю, самой большой причиной использования SVN является возможность хранения огромного, запатентованного формата, двоичных файлов под контролем версий. В частности, библиотеки тысяч файлов САПР. В этом случае он имеет смысл иметь VCS на основе файлов, как SVN, а не на основе текстовой информации, например Git.
Отложив в сторону, можете ли вы сделать мелкие "проверки" с помощью Git или насколько хорошо он хранит двоичные данные, факт состоит в том, что он разработан для отслеживания строк текстовой информации, плавающей вокруг дерево исходного кода. Как и в этом случае, эта модель не подходит для отслеживания библиотек двоичных данных.
Честно говоря, что о единственной солидной причине я бы рекомендовал: P
SVN устанавливается и созревает с одинаково зрелым инструментом.
Помимо других вещей, о которых упоминают люди, (большие количества двоичных данных, зрелые, стабильные и т.д.) заключается в том, что svn построен на классической иерархической модели, которая принципиально отличается от исправлений, основанных на исправлениях/изменениях.
Наша компания приняла решение остаться с SVN, потому что эта модель соответствует тому, как мы справляемся с нашим циклом выпуска и разветвлением. Мы видим прямое продвижение версий как благо, а не проклятие. Обновления переносятся в централизованный репозиторий, и некоторые изменения, считающиеся "стабильными", проверяются в живой среде. В любое время сразу же выясняется, каково состояние каждой среды для всех участников. (да, это возможно с помощью git.) Даже менеджеры, которые ничего не знают о контроле версий или разработке программного обеспечения, могут сказать: "Нам понравилось, как вы это делали, когда это было в версии 2547".
С другой стороны, я должен упомянуть, что я использую darcs и git для проектов, которые работают с нами и моими друзьями и со-FOSS'ерами, так как для нас работает распределенная, патч-модель. Мы можем совершать специальные действия по срокам проекта и вишневым выборам всех видов изменений.
На самом деле преимуществом SVN, моей компании, является ее сильная иерархия и доступность для не-программистов, которые уже знакомы с понятиями "входа в систему" и "загрузки".
Subversion имеет преимущество, когда репозиторий содержит множество двоичных данных, которые не дельта-сжимаются хорошо. Проверка Subversion захватывает только голову, но git клонирует всю историю, которая может весить в нескольких гигабайтах. Да, это хорошо для режима самолета, но выборка исходного клона может занять несколько часов.
Люди все еще используют Subversion, потому что они разработаны с использованием первой парадигмы для систем управления версиями (централизованно). Переход на распределенный (и на основе изменений вместо версии) может занять некоторое время, чтобы привыкнуть (как вы можете видеть в Joel experience), и поэтому многие команды решают не использовать его из-за сопротивления изменениям.
Mercurial tooling довольно зрелая, сопоставимая с SVN, на мой взгляд.
Пока svn установлен/зрелый, я должен признать, что Кенджи Кина прав: он жил в прошлом с моделью контроля версий, которая устарела. Я только использовал svn, но после прочтения/просмотра Линуса и Джоэла говорят о DVCS, это звучит как блестящая идея. Я думаю, что Perforce делает что-то подобное.
Это не значит, что svn плохо (он работает довольно хорошо!), но проще управлять своим кодом и чаще совершать транзакции с DVCS. Потому что, если вы что-то сломаете, его легко отменить. Если вы введете ветку, ее легко слить. В общем, они фиксировали множество основных головных болей, большинство из которых имеют Subversion.
Если вы никогда раньше не использовали другую систему управления версиями, и здорово развертывать ее самостоятельно, а также писать код (а не документы или картинки или вещи, для которых вам не нужны текстовые материалы/отличия), сделайте сами заглянуть в DVCS. Тогда вам не нужно быть перевоспитанным.
Пройдите через http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/