Математична бесіда: Теорема про систему контролю роботи git?

Я хотів би поговорити з математики про систему контролю ревізії git . Зараз він широко використовується в математиці, а також у галузі інформатики. Наприклад, співтовариство HoTT (Homotopy Type Theory) використовує це, і це перехід до системи спільного редагування текстових файлів, будь то вихідний код або розмітка в латексі.

Я знаю, що git використовує поняття спрямований ациклічний графік, що є початком. Однак хороша розмова з математики згадує докази та теореми.

Яку теорему я можу довести про git, яка насправді актуальна для його використання?

Репозиторій git можна розглядати як частково впорядкований набір редакцій (де одна редакція є раніше, ніж інша в порядку, якщо вона є прямим або непрямим наступником попередньої). Часткові замовлення, які ви отримуєте з репозиторіїв git, мають тенденцію до низької ширини (розмір найбільшого набору взаємозалежних ревізій), оскільки ширина безпосередньо пов'язана з кількістю активних розробників та кількістю різних вилок, якими може працювати будь-який окремий розробник. на.

Виходячи з цього фону, я б запропонував теорему Ділворта , в якій сказано, що ширина будь-якого часткового порядку дорівнює мінімальній кількості ланцюгів (повністю упорядкованих підмножин), необхідних для покриття всіх версій. І щоб зробити це на темі для цієї дошки, ви можете також згадати алгоритми, що базуються на графіках, що базуються на обчисленні ширини та знаходження кришки мінімальною кількістю ланцюгів у поліноміальний час.

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

Крім того, якщо ви хочете чогось більш амбітного та передового, спробуйте структуру даних про дерева вин Demaine et al. , Яка безпосередньо мотивується вирішенням конфліктів у системах управління версіями, схожими на git.

Цікаво, що існує зароджувана математизація систем управління версіями, хоча на даний момент це лише частково застосовно до Git. Вона називається теорією патчів [1, 2, 3, 4, 5] і виникла в контексті системи управління версіями DARCS. Це можна розглядати як абстрактну теорію розгалуження та злиття . Нещодавно теорія патчів була проведена методами HoTT [6] та категоричними [7] методами.

Теорія патчів зараз працює і не охоплює всіх аспектів контролю версій, але містить безліч теорем, які можна було б переглянути. Це чіткий приклад теорії, застосовної до "реального світу" - не дивно, бо теорія патчів - це абстракція / спрощення чогось дуже конкретного. У той же час він з'єднується з передовими математиками, такими як HoTT.

1. Дж. Дагіт, правильні типові зміни - безпечний підхід до впровадження контролю версій .
2. Г. Сіттампалам, Деякі властивості теорії патчів Дарка .
3. І. Лінах, теорія табірного шляху.
4. D. Roundy, Реалізуючи формалізм darcs patch ... і перевіряючи його.
5. Дж. Джейкобсон, Формалізація теорії патчів Дарка за допомогою зворотних напівгруп .
6. C. Angiuli, E. Morehouse, DR Licata, R. Harper, Теорія гомотопічних патчів .
7. С. Мімрам, К. Ді Джусто, категорична теорія патчів .

Іншою альтернативою є перегляд стійких (або чисто функціональних) структур даних. Внутрішня структура даних Git може розглядатися як незмінно стійке дерево :

стійка структура даних - це структура даних, яка завжди зберігає попередню версію себе при її зміні. Такі структури даних є незмінними, оскільки їх операції не (видимо) не оновлюють структуру на місці, а натомість завжди дають нову оновлену структуру.

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

Це питання також є актуальним.

Так, ви можете математично визначити, як працює Git. Ви можете визначити примітивні структури Git та операції Git на них, а потім мати теореми, які доводять, що, використовуючи ці операції, зокрема, досягаються конкретні цілі вищого рівня, або намагатися охарактеризувати чи кількісно оцінити ситуації, у яких це не так. (Наприклад, залежність Гіта від хешей залишає невеликий запас помилок.)

Інша ідея - зробити те ж саме для Subversion, потім створити теореми, які порівнюють ці дві. Наприклад, часто стверджується, що Git краще справляється зі злиттями; у вас можуть бути теореми, які це доводять якісно або кількісно.

Корисність критично залежатиме від правильних абстракцій. Математично детально описувати роботу вихідного коду Git безглуздо: сам вихідний код робить це набагато ефективніше і стисліше.