[Из песочницы] Subversion vs. Git: Развенчивание мифов о развенчивании мифов28.01.2017 23:33

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

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

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 /branches/4.7

TotalSeconds: 4.3741352

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

TotalSeconds: 1.2700857

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

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

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

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

Комментарии (8)

• lega

  28 января 2017 в 20:49

  +5

  ↑

  ↓

  Сравнение не о чем. Скорость операций — это далеко не первый пункт. Это как, если бы к вам подошел отчисленный Вася и предложил сделать операцию в 3 раза быстрее и дешевле чем квалифицированный хирург.
  Да он вроде тоже может, но результат будет отличаться.

  Туда же и mercurial (hg), я его лет пять использовал (после svn), не хотел переходить на гит, т.к. там вроде бы все тоже самое. Пришлось перейти под «давлением общественности», и не зря, т.к. гит на прядок лучше. Теперь для меня норма — то, что не приятно было трогать в hg. Продуктивность выросла, и не важно кто там быстрее клоны делает.
  

  • sabio

    28 января 2017 в 22:55

    0

    ↑

    ↓

    Расскажите, что вам было «неприятно трогать в hg», и в чём именно «гит на порядок лучше [hg]»?

  • dim_s

    28 января 2017 в 23:22

    0

    ↑

    ↓

    Все таки, если у вас корпоративный медленный svn сервер, скорость работы с ним падает еще сильнее, если какая-то операция с svn делается 10–30 секунд, то за это время можно случайно на что-то отвлечься и потерять фокус над задачей и эти 10–30 секунд превращаются в 5 минут.

• oYASo

  28 января 2017 в 22:09

  +1

  ↑

  ↓

  Какие вообще сегодня могут быть преимущества в использовании svn по сравнению с остальными vcs? Время клонирования (при котором гит еще и выкачивает 100% репозитория, в отличии от)? Ну это смешно.

  • selivanov_pavel

    28 января 2017 в 22:30 (комментарий был изменён)

    +1

    ↑

    ↓

    Одну назову — возможность дать доступ только к определённым подпапкам в репозитории. Гит такого не может архитектурно — или всё, или ничего. Редкий юз-кейс, но возможный.

    Второе — гит всё-таки надо осваивать. Не бог весть какая rocket science, но если системой контроля версий пользуются не айтишники и возможностей svn им хватает — зачем заставлять людей тратить время и силы на непрофильные вещи?

• Jaromir

  28 января 2017 в 22:40 (комментарий был изменён)

  0

  ↑

  ↓

  Git так и не научился отдавать один файл/директорию без скачивания всего репозитория со всеми изменениями? Менеджеры пакетов, постоенные на git так и качают 95 избыточных процентов в виде папки .git для каждого пакета?

  • lega

    28 января 2017 в 22:52

    +2

    ↑

    ↓

    В git можно задать (глубину) depth, и скачать только один «срез».
    

• VBKesha

  28 января 2017 в 23:29

  0

  ↑

  ↓

  А еcли для svn сделать svnadmin pack и посмотреть размер?