Subversion vs. Git: Развенчивание мифов о развенчивании мифов

в 17:14, , рубрики: Git, svn, Системы управления версиями

Subversion vs. Git: Myths and Facts утверждает, что развеивает некоторые мифы о системах контроля версий. Я усомнился в их «фактах» и проверил некоторые из них. Результатом проверки стал подорванный авторитет сайта, и скептическое отношение к остальным утверждениям.

Немного о том, почему меня это заинтересовало

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

Однажды я стал свидетелем обсуждения этой темы. Коллеги обсуждали тот самый сайт и пришли к выводу, что «меняем шило на мыло».
В этом диалоге я был невольным слушателем, но что там за сайт и его аргументы меня заинтересовали. Пошел разбираться.

Начнем с первого заявления

Git repositories are significantly smaller than equivalent Subversion ones
False. A myth.

The particular delta compression algorithms used in both version control systems differ in many details, but in general Subversion and Git store data in the same way. This results in the fact that Subversion and Git repositories with equivalent data will have approximately the same size. Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files).

Ниже есть пример, где они сравнивают размер репозитория. Вывод – разница не существенна.

Меня смутило различное число коммитов, и фактически разные первоисточники(кто знает, как они там синхронизируют эти репозитории). Так же меня не устроил уровень детализации описания процесса получения этих чисел.

Итак, начнем свой эксперимент!

Получаем svn репозиторий

svnrdump.exe dump https://core.svn.wordpress.org/ > svndump
svnadmin create svn
svnadmin load svn < svndump 

У нас локальная копия всего репозитория в формате svn. Это папка размером 213 МБ, которая содержит 79758 файлов и 88 папок.

На этот момент в репозитории насчитывается 39864 коммита. Рабочая копия проекта состоит из 1701 файла и 160 папок.

Начинаем миграцию в гит

git svn clone -s --prefix "svn/" file:///%path%/svn git_from_svn 

Этот этап был самым длительным, затянулся более чем на сутки (примерно 32 часа). В результате имеем git репозиторий — копия оригинального svn репозитория(не совсем копия, но для нас различия не существенны).

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

Итак, папка git_from_svn/.git: 208 МБ содержит 7841 файлов и 509 папок. На данном этапе действительно можно говорить о незначительном перевесе в пользу git, видимо как раз на этом этапе и остановились те, кто ведет сайт. Но ведь у гита есть 2 формата хранения: “loose” object и “packfile".

Посмотрим, что же мы имеем:

git count-objects -v -H

Результат:

count: 6826
size: 30.21 MiB
in-pack: 249852
packs: 25
size-pack: 145.51 MiB
prune-packable: 73
garbage: 0
size-garbage: 0 bytes

То есть у нас есть множество пакетов и 6826 (30.21 МБ) не сжатых объектов.

Оптимизируем хранение

git gc
git count-objects -v -H

Результат:

count: 0
size: 0 bytes
in-pack: 256605
packs: 1
size-pack: 104.54 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

Размер самой папки ".git" получается 136 МБ(945 файлов, 255 папок). Мне кажется такое преимущество уже сложно назвать незначительным.

Еще подчистим

Но и это еще не все, если избавиться от наследия svn — пушнуть это все в bare репозиторий получаем еще интересней картинку: 106 MБ, 19 файлов, 8 папок.

Соберем все вместе

svn — 213 MБ (79 758 файлов, 88 папок)
git svn — 208 MБ (7 841 файлов, 509 папок)
git svn(pack) — 136 MБ (945 файлов, 255 папок)
git bare(pack) — 106 MБ (19 файлов, 8 папок)

Мне кажется на этом этапе развенчивание мифа можно считать развенчанным(утверждение на сайте опровергнуто).

Еще стоит упомянуть, что loose объекты у вас все же будут, предназначены они для повышения производительности работы с часто используемыми файлами. Обычно в таком формате будут храниться файлы из веток, в которых сейчас активно идет работа. Их количество можно регулировать через конфигурационные файлы.

Идем дальше

Branches are expensive in Subversion
False. A myth.

Branches in Subversion are implemented with Copy-On-Write strategy (referred to as ‘Cheap Copies’ in the svnbook). No matter how large a repository or project is, it takes a constant amount of time and space to make a branch. In fact, Subversion branches are extremely cheap beginning with version 1.0 and you can branch even for small bugfixes in a very busy and large project.

И эксперимент это «подтверждающий».

Вывод – создание бранчи происходит быстрей чем вы газом успеете моргнуть. Мне показалось, что если вся операция занимает меньше 0,01 секунды то тут и сравнивать нечего. Но почему-то на заявление о дороговизне бранчей в svn, сайт проверил только их создание. Но есть другие операции, например клонирование( или svn checkout). В этом эксперименте все происходит локально, возможное влияние сети исключено.

Первый эксперимент – клонирование

svn checkout %local_path%/trunk

TotalSeconds: 14.0737539

git clone %local_path%

TotalSeconds: 21.8173709

Git проиграл. Но здесь стоит учесть, git получил всю историю, а svn — одну ревизию.

Второй эксперимент – смена бранчи

svn switch <local_path>/branches/4.7

TotalSeconds: 4.3741352

git checkout -B "4.7" "origin/4.7"

TotalSeconds: 1.2700857

Здесь все наоборот, при этом на одном переключении мы отыграли половину от потери при клонировании.

На этом я пожалуй закончу. Пойду обсуждать эти результаты с сотрудниками.

PS: Несмотря на то, что посыл этой заметки банален «не стоит доверять непроверенным источникам в интернете», но, оказывается, есть еще люди, не развившие достаточный уровень здорового скептицизма.

Спасибо за внимание!

Автор: ki0

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js