Subversion vs. Git: Розвінчання міфів про розвінчанні міфів

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 МБ, 19 файлів, 8 папок.

Зберемо всі разом

svn — 213 МБ (79 758 файлів, 88 папок)
git svn — 208 МБ (7 841 файлів, 509 папок)
git svn(pack) — 136 МБ (945 файлів, 255 папок)
git bare(pack) — 106 МБ (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 a large 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: Незважаючи на те, що посил цієї замітки банальний «не варто довіряти неперевіреним джерелам в інтернеті», але, виявляється, є ще люди, не розвинули достатній рівень здорового скептицизму.

Спасибі за увагу!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.