Чому сховища Git / Mercurial використовують менше місця?


15

Я читав на декількох дискусіях тут і в ТА, що сховища DVCS використовують приблизно той самий або менший простір, ніж їх централізовані зустрічні частини. Я, можливо, це пропустив, але я не знайшов хорошого пояснення, чому це так. Хтось знає?


5
Чи читаєте ви наступні публікації? stackoverflow.com/questions/7727791 / ... або stackoverflow.com/questions/8657710 / ... або stackoverflow.com/questions/456336 / ...
VonC

1
Я ні, дякую! Тому я розумію, що є дві відповіді: стиснення за допомогою zlib та збереження об'єктів як пакетних файлів, коли це можливо. Приклади Mozilla також чудові!
Алекс Флореску

1
@ Алекс Ні, це не вистачає головної причини. SVN зберігає повні знімки, Git та Mercurial зберігають лише перегляд HEAD та відрізняються. Використання звичайної компресії може забезпечити найкращі показники стиснення близько 60–80%. Використання різниць може отримати 99%. Ці числа витягнуті з моєї дупи, хоча реальні цифри можуть відрізнятися; тенденція буде такою ж , хоча.
Конрад Рудольф

@KonradRudolph, чи не про те, про що йдеться у пакетних файлах?
Алекс Флореску

@Alex Не дуже. Наскільки я знаю, пакет файлів додатково пакує кілька файлів в один. Це не обов'язково пов'язано.
Конрад Рудольф

Відповіді:


18

З мого власного досвіду, такі твердження справжні:

  • Git дуже ефективний для зберігання текстових файлів і лише для зберігання цих файлів, які були змінені. тому при порівнянні SVN та Git для порівняння розмірів сховищ вони можуть бути схожими, або може бути навіть невелика перевага для Git.
  • Це абсолютно неправильно, якщо порівнювати розміри сховищ, де значна кількість файлів є офісними файлами (наприклад, MS word, excel, powerpoint, ...). Тут Git також зберігає повні копії, а це означає, що 10 невеликих змін на стеку слайдів Powerpoint призводять до 10 повних копій, де Subversion зберігає лише двійкову різницю, що може бути в 100 разів менше.

Якщо порівнювати місце оформлення каси (яке саме по собі є сховищем з Git), історія зовсім інша:

  • Subversion зберігає для кожного файлу повну копію, тому розмір місця вашого замовлення, як правило, в 2 рази перевищує розмір самих файлів.
  • Git зберігає повну історію сховища на локальному рівні, тому залежно від розміру історії він може бути меншим або значно більшим, ніж у копії каси Subversion.

Якщо ви порівнюєте кількість байтів, які вам доведеться зменшити чи завантажити, то вона знову відрізняється.

  • Субверсія зазвичай має надсилати або отримувати менше байтів, оскільки вона надсилає лише відмінності. Це потрібно робити під час кожного введення та оновлення.
  • Git повинен отримати весь сховище (спочатку), а потім надсилає цілі файли (стиснуті?), Які не такі різні для текстових файлів, але можуть бути різними для бінарних файлів. І так, Git робить це лише тоді, коли щось натискаєш або витягуєш до віддаленого сховища.

Тож наприкінці ви порівнюєте яблука з апельсинами, і залежно від того, що ви хочете робити із Subversion або Git, результат може бути різним.


@jk запитав про повні копії чи бінарні розбіжності, і я не зміг відповісти на це питання. Я запитав Метью Маккаллоу, який нещодавно влаштував семінар Git на Jax 2012 (який я відвідав). Він узяв час (дуже йому дякую), щоб детально пояснити внутрішню роботу Git. Так, так, там працює компресія (і я проведу експеримент і з офісним файлом мікрософт, і порівняю його зі своєю суттю), але ні, стиснення робиться на весь файл. Посилаючись на його суть:

Вільні об'єкти записуються у стисненому, але недельтатному форматі під час кожного вчинення.


1
Ви впевнені, що git зберігає повні копії офісних файлів? Я думаю, що він також зберігає двійкові відмінності. Звичайно, справді проблема з такими файлами полягає в тому, що вони часто вже стиснуті, тому невелика зміна може призвести до зміни всього файлу
jk.

2
Запитав когось (електронною поштою), який знає набагато більше, ніж я, і включить його відповідь у свою відповідь тоді.
mliebelt

6
Git трактує текстові та двійкові файли точно однаково у всіх та будь-яких стосунках щодо зберігання. Об'єкти, що розпущені та упаковані, не мають відношення до тексту та двійкових. Причина, що двійкові файли часто призводять до набагато більших відмінностей, ніж текстові файли, полягає в тому, що багато бінарних форматів (включаючи всі нові офісні формати) вже стиснуті, і тому навіть невелика зміна вмісту часто спричиняє великі зміни в отриманій бінарній крапці. Це однаковою мірою стосується git та subversion, але субверсія бере лише штраф на сервер, тоді як git скрізь.
Ян Худек

4
Вільні об'єкти та упаковані об'єкти не мають нічого спільного з текстом та бінарними. Це амортизація непростої роботи з пошуку двійкового різниться. Швидкість є важливою особливістю git, тому під час регулярної роботи git лише переносить нові дані та тримає їх у сховищі. Це сипучі предмети. Тоді, коли ви попросите його, зателефонувавши git gcабо накопичивши занадто багато пухких об'єктів, він знаходить хороших кандидатів для дельта-стиснення (git може відрізнятися від попередньої версії), зберігає дельти в "пачку" і видаляє сипучі об'єкти.
Ян Худек

3
Для тих, хто цікавиться номерами в реальному світі: я щойно порівняв дві робочі екземпляри з того самого репо. Робоча копія SVN становить близько 2,9 ГБ, робоча копія GIT - близько 0,8 ГБ.
JensG
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.