Почему использовать SVN? Какие-либо скрытые профессионалы (по МЕРЗАВЦУ/ПОДВИЖНОМУ/БАЗАРУ) там? [дубликат]

Пройдите через это http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-gotits/

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

Mercurial инструменты достаточно зрелые, сравнимые с SVN, на мой взгляд.

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

Наша компания приняла решение остаться с SVN, потому что эта модель соответствует тому, как мы работаем с нашим циклом выпуска и ветвлением. Мы считаем прямое продвижение версий благом, а не бедой. Обновления поступают в централизованный репозиторий, а определенные ревизии, считающиеся "стабильными", проверяются в живой среде. В любой момент времени всем участникам процесса становится ясно, в каком состоянии находится каждая среда. (Да, это возможно с помощью git.) Даже руководство, которое ничего не знает о контроле ревизий или разработке программного обеспечения, может сказать: "Нам нравилось, как у вас было, когда версия была 2547".

С другой стороны, я должен упомянуть, что я использую darcs и git для проектов, над которыми я и мои друзья и со-французы работаем вместе, так как распределенная, основанная на патчах модель работает для нас. Мы можем ad-hoc перемещаться по временной шкале проекта и выбирать любые изменения.

Действительно, преимущество SVN, по мнению моей компании, заключается в его сильной иерархии и доступности для непрограммистов, которые уже знакомы с понятиями "вход в систему" и "загрузка".

SVN устоявшаяся и зрелая, с столь же зрелым инструментарием.

В настоящее время я обслуживаю службу контроля версий для исследовательского учреждения США. Мы поддерживаем не только SVN в дополнение к Git и Mercurial, но и CVS.

«Убийственная особенность» SVN среди наших пользователей - это узкие клоны. Вы можете проверить только один подкаталог глубоко в иерархии, загрузить только файлы, относящиеся к этому каталогу, и по-прежнему иметь возможность совершать коммиты. Совсем недавно Git предоставил похожий, но не столь полезный вариант этой функции, называемый разреженной проверкой (см. Также Разреженная проверка в Git 1.7.0? ). Это позволяет фильтровать ваше рабочее дерево, но по-прежнему заставляет вас загружать всю историю всего проекта, что может быть недопустимым, даже если большие двоичные файлы не задействованы .Имейте в виду, диск дешевый, и если вы поглотите удар первоначального клона заранее, последующие попытки будут достаточно быстрыми, но это не поможет людям, которые отправились в путешествие до того, как осознали, что им нужно клонировать, и в любом случае даже Редкие проверки в Git не позволят вам начать рабочее дерево на пять уровней ниже, поэтому оно выглядит немного некрасиво.

Кроме того, пользователи считают, что файлы authz легче писать, чем перехватчики фиксации Git, им удобнее использовать синтаксис и методологию SVN, чем любой DVCS, и, что, возможно, самое главное, уже имеет много тысячи коммитов в истории SVN . Эксперименты по переносу больших репозиториев Subversion на Git или Mercurial дали смешанные результаты, и это ученые, пытающиеся выполнить работу над своими собственными проектами, не жертвуя своим временем на разработку DVCS.

CVS все еще имеет последователей по той же причине. Представьте себе, как у пользователя Git есть разреженные проверки, которые также позволяют вам произвольно переназначать, где файлы в ветке отображаются в вашем рабочем дереве, используя формат, который версируется вместе с репозиторием и распространяется при каждом обычном извлечении, что позволяет вам для написания определений, которые могут иметь группы, которые могут включать в себя другие группы, и которые только извлекают файлы, необходимые для размещения файловой системы на клоне. Это просто в модулях CVS и невозможно в каждой DVCS.Несмотря на все грехи CVS (и поверьте мне, мы хорошо о них знаем и изо всех сил стараемся препятствовать новым проектам CVS, если они не могут жить без модулей), невозможно убедить группу, используя эту функцию для перехода на другую систему контроля версий.

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

Несмотря на то, что svn уже установлен / зрел, я должен признать, что Кенджи Кина прав: он живет прошлым с моделью контроля версий, которая устарело. Я использовал только svn, но после прочтения / просмотра разговоров Линуса и Джоэла о DVCS это звучит как блестящая идея. Я думаю, что Perforce делает нечто подобное.

Это не значит, что svn плохой (он работает неплохо!), Но с помощью DVCS легче управлять своим кодом и чаще совершать коммиты. Потому что, если вы что-то сломаете, это легко отменить. Если вы разветвляетесь, его легко объединить. В общем, они устранили многие основные головные боли, возникающие при работе с Subversion.

Если вы никогда раньше не использовали другую систему управления версиями и хорошо умеете ее развертывать и писать код (а не документы, изображения или вещи, для которых вам не нужны текстовые материалы / различия), сделайте себе пользуйтесь и посмотрите в DVCS. Тогда тебе не нужно будет перевоспитывать .

Если говорить о компании, в которой я работаю, то самой большой причиной использования SVN является возможность держать под контролем версий огромные бинарные файлы проприетарного формата. В частности, библиотеки из тысяч файлов CAD. В этом случае действительно имеет смысл, чтобы VCS была основана на файлах, как SVN, а не на текстовой информации, как Git.

Если отбросить вопрос о том, можете ли вы делать неглубокие "проверки" в Git, или насколько хорошо он хранит двоичные данные, факт в том, что он предназначен для отслеживания строк текстовой информации, плавающей вокруг дерева исходного кода. Как бы хорошо она это ни делала, эта модель не подходит для отслеживания библиотек двоичных данных.

Честно говоря, это единственная веская причина, по которой я бы рекомендовал его использовать :P

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