Чем SVN лучше Git?

В чем преимущества одной и другой системы контроля версий?

p.s: задался таким вопросом, когда услышал от коллеги "когда будем использовать нормальную svn"
  • Вопрос задан
  • 9218 просмотров
Решения вопроса 1
@miksir
IT
Основные отличия - гита от svn - распределенность и хорошая поддержка ветвлений в разработке (ветки).

SVN, конечно же, поддерживает ветки, но при сложных ветвлениях (ветки мержатся между собой) случаются неожиданные конфликты и т.п. Хотя, если у вас классическая схема - фича-ветка от мастера (транка) и обратный мердж в мастер (транк) - разница почти незаметна.

Про распределенность: у SVN центральный сервер, у гита - граф серверов, хотя 99% процентов разработчиков используют локальный репо + один удаленный, т.е. по сути - тот же центральный сервер. Зато, так как репа локальная, гит очень быстр в переключении веток.

Есть еще куча различий и, как плюсов, так и минусов у каждого ПО. Хотя сегодня SVN все реже и реже можно встретить, но в общем для многих рабочих групп его вполне достаточно для полноценной работы. С другой стороны - знать git тоже обязательно сегодня, ибо почти стандарт ;)

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


Но я бы не стал говорить, что svn нормальный, а git нет. Просто он другой и со своими тараканами. Сам долгое время работал на SVN, потом потихоньку перебрались на git в основном из-за подводных камней сложного ветвления.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
sim3x
@sim3x
свн - централизированное хранилище
Такой кейс очень редок
свн стоит использовать если с проектом будет работать один человек
Ответ написан
@LeeSoft
Php, Python, Flask
Единственный плюс -- линейная нумерация коммитов. Получается human-like хронология.
Ответ написан
Комментировать
Vapaamies
@Vapaamies
Разработчик будущей ОС для ПК размером 250 МБ
SVN лучше Git тем, что не пытается превратить твою Винду в Юникс и не тащит за собой кучу мусо... э-э-э, зависимостей, которые проистекают от нежелания разработчиков Git договориться и написать всё на одном языке... или не на одном, но компилируемых, чтобы потом собрать объектный код в исполнимые модули.

Поэтому SVN -- это 5 метров EXE/DLL самого SVN, а Git -- 200 (400?) метров, включающих в себя MSYS, Cygwin и Perl помимо самого Git. Для кого размер не аргумент -- есть понятие сложности владения: в большой и сложной системе больше точек, где что-то может сломаться.

Насчет поколений и распределенности никто не спорит. Просто так сложилось, что к моменту появления распределенных VCS несистемные программисты перестали писать на компилируемых языках... В смысле однородности Mercurial лучше, но Python медленный, зараза!
Ответ написан
@Dmitry_Barovik
Дополню недостатки git:
1) В git невозможно изменить комментарий уже закоммиченной ревизии, т.к. комментарий включается в хэш самого коммита. Для чего это может быть нужно? Мы храним в SVN не только исходники ПО, но и базу данных (схему, хранимые процедуры и некоторые данные). И у нас автоматизирована сборка пакетов обновлений в случае изменений базы данных. Этот сборщик проходит по коммитам и генерирует последовательно файлы с SQL-кодом, которые необходимо выполнить в нужном порядке, чтобы применились изменения в базе у заказчика. Так вот, в комментариях к коммитам мы придумали и пишем некоторые специальные команды для сборщика, чтобы он знал, что из данной ревизии надо подготовить (или наоборот пропустить) какие-то SQL-команды или выполнить их с какими-то особенностями. В случае, если программист сделал ошибку, мы можем просто изменить комментарий и например указать, что эту ревизию надо исключить из сборки.

2) В git, если вы переименуете папку, то придется закоммитить ВСЕ ФАЙЛЫ И ПАПКИ внутри. Т.к. git хранит не имя файла, а полный путь. В SVN не надо как идиот этого делать (например в TortoiseGit миллион птичек надо ставить на все вложенные файлы), и если переименовал одну папку, то и коммитишь только эту папку.

3) В .git внутри репозитория нельзя создать подпапку с отдельным репозиторием. В SVN без проблем, можно в существующую подпапку сделать “checkout” другого репозитория.

4) Чтобы установить TortoiseGit, придется к себе на компьютер ставить и сам git.
Что для svn вообще не требуется. Админы развернули SVN (т.е. Apache Subversion) где-то на сервере организации, а программисты установили TortoiseSVN утилитку маленькую и работают.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы