Что SVN может сделать, что Git не может?

Question

Я сейчас глубоко в Git до того, как освоил SVN. Это мой первый серьезный опыт обучения системы управления исходным кодом.

Я удивляюсь альтернативной стоимости неучения (или даже лишению обучения того, о чем я мало узнал) SVN. Есть ли что-то, что я должен остерегаться?

Есть ли вещи, которые просто не выполнимы или непомерно трудны в Git по сравнению с SVN?

Answer 1

Git не может svn lock документов, чтобы кто-то мог помешать другим редактировать не-автоматически объединяемые объекты (такие как файл Word или Excel).

Answer 2

Git не может извлечь поддерево и использовать его так, как если бы оно было полным хранилищем.

Например, в Subversion вы можете проверить каталог "trunk" и использовать его, как если бы оно былорепозиторий.Вы также можете проверить «ветки / feature1» и использовать это.С помощью Git можно только извлечь корневой каталог (хотя в последних версиях вы можете делать редкие проверки, которые не загружают все файлы, вам все равно придется проверять корневой каталог).В Git вы используете ветки вместо проверки поддеревьев.

Answer 3

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

Чтобы быть справедливым для git, это пример использования, который очень далек от того, для чего он предназначен (управление репозиториями исходного кода), и существуют различные обходные пути или расширения, которые могут помочь, если вы действительно хотите использовать git для этого, например:

• Мелкие клоны
• Скотт Чакон git-media расширение
• аналогичный проект Джои Хесса, git Annex
• Использование Avery Pennarun bup для непосредственного создания файлов пакета

... но это все еще область, где можно было бы предпочесть SVN. На эту тему есть краткая презентация от GitTwo пару лет назад.

Answer 4

Git не может хранить пустые каталоги.Возможно, это преимущество, но это одна вещь, которую git не может сделать, а svn может.

Answer 5

В этой вики есть приятное сравнение: https://git.wiki.kernel.org/index.php/GitSvnComparison

Обобщенная

• Git намного быстрее, чем Subversion
• Subversion позволяет вам проверить только поддерево хранилища; Git требует, чтобы вы клонировали весь репозиторий (включая историю) и создали рабочую копию, которая отражает по крайней мере подмножество элементов, находящихся под контролем версий.
• Репозитории Git намного меньше, чем Subversions (для проекта Mozilla, в 30 раз меньше)
• Git был спроектирован так, чтобы полностью распространяться с самого начала, что позволяет каждому разработчику иметь полный локальный контроль
• Ветви Git проще и менее ресурсоемки, чем Subversion
• Ветви Git несут всю свою историю
• Слияние в Git не требует, чтобы вы помнили ревизию, с которой вы слились (это преимущество было устранено с выпуском Subversion 1.5)
• Git обеспечивает лучший аудит событий ветвления и слияния
• Форматы файлов репозитория Git просты, поэтому восстановление легко, а повреждение редко.
• Централизованное резервное копирование репозиториев Subversion потенциально проще - поскольку вы можете выбрать для распределения папок внутри репозитория в git
• Клоны репозитория Git действуют как полные резервные копии репозитория
• Пользовательский интерфейс Subversion более зрелый, чем у Git
• Проходить по версиям проще в Subversion, потому что он использует последовательные номера ревизий (1,2,3, ..); Git использует непредсказуемые хэши SHA-1. Ходить назад в Git легко, используя синтаксис «^», но нет простого способа идти вперед.

Answer 6

• Git не имеет серьезной (независимой от платформы) поддержки не-US-ASCII символов в именах файлов и сообщениях о фиксации, git просто хранит байтовое представление символов, которые он получает из ОС, вместо того, чтобы переводить его.
• Git не может записать, какие именно коммиты были выбраны вишней.

Answer 7

Subversion - это центральное хранилище

В то время как многие люди хотят иметь распределенные репозитории для очевидных преимуществ скорости и нескольких копий, бывают ситуации, когда центральный репозиторий более желателен. Например, если у вас есть какой-то критический фрагмент кода, к которому вы не хотите, чтобы кто-то имел доступ, вы, вероятно, не захотите помещать его в Git. Многие корпорации хотят сохранить свой код централизованным, и (я полагаю) все (серьезные) правительственные проекты находятся в центральных хранилищах.

Подрывная деятельность - это общепринятая мудрость

Это означает, что многие люди (особенно менеджеры и начальники) имеют обычный способ нумерации версий и видят развитие как «единую линию» в течение времени, жестко запрограммированную в их мозгу. Без обид, но либеральность Git нелегко проглотить. Первая глава любой книги по Git говорит вам, чтобы вычеркнуть из головы все условные идеалы и начать все заново.

Subversion делает это одним способом, и ничем иным

SVN - система контроля версий. У него есть один способ сделать свою работу, и все делают это одинаково. Период. Это позволяет легко переходить в / из SVN из / в другие централизованные VCS. Git даже не чистый VCS - это файловая система, имеет много топологий для настройки репозиториев в различных ситуациях - и не существует никакого стандарта. Это затрудняет выбор.

Другие преимущества:

SVN supports empty directories
SVN has better Windows support
SVN can check out/clone a sub-tree
SVN supports exclusive access control svn lock which is useful for hard-to-merge files
SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.

Нашел и согласен с этим. Опять же, когда ты касаешься мерзавца, новички довольно агро. Я не могу доверять git или github до тех пор, пока не произойдет еще несколько изменений в безопасности, таких как переход на один шаг дальше от взломанных ключей ssh.

Answer 8

Вы не можете ограничить доступ для чтения к части репо (т.е. разрешить чтение только определенных файлов или только часть истории). Это является прямым следствием того факта, что вы можете клонировать только полный репозиторий (как объяснено в ответах Тео и Марка Лонгаира). Если вам нужны разные уровни доступа для чтения для разных файлов, вы должны поместить их в разные репозитории (которые могут быть включены в качестве субмодулей в основной репозиторий).

Обратите внимание, что вы можете ограничить доступ на запись в репо по многим критериям (путь, имя файла, изменение истории). Вам нужно использовать специальное программное обеспечение в дополнение к git для этого (например, gitosis ), но это похоже на Subversion.

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

Answer 9

Для нас наиболее важной особенностью SVN является возможность блокировки файлов репозитойой.Так как мы работаем с двоичными и непогружаемыми файлами CAD, рабочий процесс на основе слияния любой DVCS здесь не работает.

Answer 10

Я бы сказал, что вы можете делать практически все, что имеет значение в git, и даже больше, чем позволяет подрывная деятельность.Это не должно быть твоим беспокойством.Однако оба они популярны и заслуживают вашего внимания, особенно если вы занимаетесь программированием с открытым исходным кодом.

Однако я бы посчитал, что git сложнее в освоении, но как только вы освоитесь с этим, люди обычно становятся зависимыми и считают других SCM неполноценными.Распределенная поддержка git превосходна (есть и другие, но git, вероятно, является наиболее распространенным), которая оказывается полезной для множества других задач, помимо управления одним исходным кодом.git может рассматриваться как ZIP-утилита на стероидах и может быть быстро развернута для отслеживания общих изменений файловой системы и эффективной репликации изменений между хостами.

В windows есть некоторые проблемы с git:

• Поддержка имени файла Unicode во многих реализациях содержит ошибки.Это все время улучшается, но все же это проблема.
• Плагины Explorer не так хороши в Windows.Вместо этого мне проще использовать версию командной строки.

Но я бы рассмотрел вещи, которые есть у git, а у SVN нет.Отсутствие явной поддержки веток в SVN является серьезной проблемой - реализация git очень удобна и позволяет вам ветвиться, даже не думая о ветвях.Возможность работать в автономном режиме также очень важна.