Чому системи управління джерелами все ще підтримуються файлами?

22

Здається, що більшість систем управління джерелами все ще використовують файли як засіб зберігання даних про версії. Сейф і TFS використовують сервер Sql як сховище даних, що, на мою думку, було б краще для послідовності даних та швидкості.

То чому саме SVN, я вважаю, GIT, CVS і т. Д. Все ще використовують файлову систему як по суті базу даних (я задаю це питання, оскільки наш сервер SVN просто пошкодив себе під час звичайної фіксації) замість того, щоб використовувати фактичне програмне забезпечення бази даних ( MSSQL, Oracle, Postgre тощо)?

EDIT: Я думаю, що інший спосіб задати моє запитання: "чому розробники VCS прокручують власну структуровану систему зберігання даних замість того, щоб використовувати існуючу?"

version-control

— Енді
джерело

29

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

— Йоахім Зауер

2

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

1

@JoachimSauer Так, я це розумію, але в системах DBM є способи гарантувати, що нічого непослідовного не потрапляє в базу даних. Якщо ці файлові сховища не використовують щось на зразок Transactional NTSF, все ще існує можливість пошкодження. І я більше довіряю справжній базі даних, ніж я складаю набір розробників, які по суті переосмислюють колесо, оскільки, думаю, ми можемо погодитися, що системи управління джерелами потребують цілісності даних.

— Енді

2

@delnan Транзакційна підтримка та внутрішня послідовність. Зараз ми відновлюємо наш сховище SVN з стрічки b / c, сервер SVN не записував належним чином у всі файли, які він повинен був. Також проводиться пошук величезних обсягів даних. Моя думка, чому б спробувати переосмислити колесо.

— Енді

7

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

— GlenPeterson

23

TL; DR: небагато систем управління версіями використовують базу даних, оскільки це не потрібно.

Як питання для відповіді на питання, чому б не зробити це? Які переваги пропонують "реальні" системи баз даних над файловою системою в цьому контексті?

Вважайте, що контроль за редакцією здебільшого відстежує невеликі метадані, і багато тексту різняться. Текст не зберігається в базах даних більш ефективно, і індексабельність вмісту не буде фактором.

Припустимо, що Git (для аргументу) використовував БДБ або SQLite БД для свого резервного копіювання даних. Що було б надійніше в цьому? Все, що може пошкодити прості файли, може також пошкодити базу даних (оскільки це також простий файл із складнішим кодуванням).

Із парадигми програміста не оптимізувати, якщо це не потрібно, якщо система управління ревізією досить швидка і працює досить надійно, навіщо змінювати всю конструкцію, щоб використовувати більш складну систему?

— мікебаккок
джерело

2

TLDR? Ви відповідали вдвічі довше, і питання було справді коротким!

— Бред

25

@Brad Три слова, що слідують за, TL;DR- це скорочена версія відповідей, а не твердження, що питання занадто довге, і він не прочитав його, перш ніж відповісти.

6

@Andy Mercurial також має "греп в історії", і git, ймовірно, має і його. Це також вже блискавично. Що стосується того, щоб залишити речі експертам: люди, які розробляють СКС, - це експерти.

3

Просто хочу додати, що я бачу вашу думку; якщо VCS записує погані дані, не має значення, чи записує їх у файл чи базу даних. Зворотний бік, однак, це те, що репо-файли на основі файлів, ймовірно, записуються в більш ніж один файл одночасно, і зазвичай для цього не існує транзакційної підтримки, тому якщо один файл пише, але інший не вдасться, ваш VCS пошкоджений, проти неперевершеної таблиці пише в базі даних транзакція буде здійснена за провал як одиниця. Мені здається, що група програмного забезпечення баз даних розробників має з цим більше досвіду, ніж люди, що пишуть SVN ... але, можливо, я помиляюся.

— Енді

6

Ваш вибір git "заради аргументів" є важливим моментом тут: git має дуже гарну модель для написання своїх об'єктів, але багато інструментів цього не роблять. Якщо git, якщо комп'ютер вимкнений посеред комітету, ви записали деякі об’єкти у файлову систему, і вони будуть просто недоступними. З іншими VCS ви можете додати зміни до половини файлів (і виникає плутанина.) Ви можете стверджувати, що інші інструменти керування версіями погано розроблені (і ви матимете рацію), але коли ви пишете VCS, це набагато простіше просто використовувати транзакцію SQL і нехай це робить правильно.

— Едвард Томсон

25

Ви, здається, робите багато припущень, можливо, виходячи з вашого досвіду роботи зі SVN та CVS.

Git та Mercurial в основному схожі на SVN та CVS

Порівнювати git та CVS - це як порівнювати iPad та Atari. CVS був створений ще коли диноаври блукали по Землі . Subversion - це в основному вдосконалена версія CVS. Якщо припустити, що сучасні системи керування версіями, такі як git та Mercurial, як і вони, мають дуже мало сенсу.

Реляційна база даних є більш ефективною, ніж одноцільова база даних

Чому? Реляційні бази даних дійсно складні і можуть бути не настільки ефективними, як цільові бази даних. Деякі відмінності від моєї голови:

Системам управління версіями не потрібно складне блокування, оскільки ви не можете одночасно робити кілька коміксів.
Системи управління розподіленими версіями повинні бути надзвичайно просторовими, оскільки локальна база даних є повною копією репо.
Системам контролю версій потрібно лише шукати дані двома конкретними способами (за автором, за ідентифікатором редакції, іноді повнотекстовим пошуком). Створення власної бази даних, яка може обробляти пошук авторів / ревізійних ідентифікаторів, є тривіальною, а повнотекстовий пошук не дуже швидкий у будь-якій реляційній базі даних, яку я намагався.
Системам управління версіями потрібно працювати на декількох платформах. Це ускладнює використання бази даних, яку потрібно встановити та запустити як сервіс (наприклад, MySQL або PostgreSQL).
Системи контролю версій на вашій локальній машині повинні бути запущені лише тоді, коли ви щось робите (наприклад, виконувати зобов'язання). Залишати такий сервіс, як MySQL, що працює весь час, лише на випадок, якщо ви хочете зробити зобов’язання, марно.
Здебільшого системи контролю версій ніколи не хочуть видаляти історію, просто додайте її. Це може призвести до різних оптимізацій та різних методів захисту цілісності.

Реляційні бази даних безпечніші

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

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

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

Повторно винаходити колесо - це погано

Тільки тому, що ви можете використовувати реляційну базу даних для будь-яких проблем із зберіганням, не означає, що вам слід . Чому ви використовуєте файли конфігурації замість реляційної бази даних? Навіщо зберігати зображення у файловій системі, коли ви могли зберігати дані у реляційній базі даних? Навіщо зберігати свій код у файловій системі, коли ви могли зберігати все це у реляційній базі даних?

"Якщо у вас є молоток, все виглядає як цвях".

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

Що стосується того, чому ми б довірили авторам систем контролю ревізії знати, що вони роблять? Я не можу говорити за інші VCS, але я впевнений, що Лінус Торвальдс розуміє файлові системи .

Чому деякі системи контролю комерційних версій тоді використовують реляційну базу даних?

Швидше за все, комбінація з наступного:

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

— Відновіть Моніку
джерело

1

Одне: SVN-зобов'язання є атомними. Насправді, це головне місце продажу (або, принаймні, тоді, коли їм довелося переконати користувачів CSV переключитися).

1

@delnan - Зауважте, що існує велика різниця між теоретичною атомністю, яку ви отримуєте, svnколи різні каталоги у вашому робочому каталозі можуть знаходитись у різних svnредакціях, і справжню атомність широкого сховища, яку ви отримуєте з gitабо hg.

— Марк Бут

2

@Andy І я можу сказати, що ти можеш працювати з тими самими сценаріями без повноцінної реляційної бази даних. Якщо дві людини здійснюють в той самий час, сервер може робити один за одним. Це не складна можливість втілити в життя. Якщо ви хочете зробити це з місцевим користувачем, просто створіть файл блокування. Коли ви починаєте виконувати комісію, отримайте блокування у файлі. Коли ви закінчите комісію, відпустіть замок. Якщо ви хочете дозволити здійснення комісій для декількох гілок одночасно, використовуйте файл блокування для кожної гілки. Звичайно, SQLite зробив би це для мене, але це не обов'язково .

— Відновіть Моніку

1

Так само не є складним впровадження базового журналу. (1) Випишіть нову фіксацію файлу. (2) Скопіюйте старий індексний файл. (3) Напишіть новий індексний файл. (4) Видаліть копію старого файлу індексу. Якщо ви не виконаєте кроки 1, 2 або 4, вам потрібно просто очистити створені вами нові файли. Якщо на кроці 3 не виходить, просто потрібно скопіювати старий індексний файл назад. Хтось, хто краще розуміє файлові системи, міг би зробити набагато ефективнішу версію цього, але ви завжди можете посилатися на вихідний код SQLite, якщо вам потрібно (це загальнодоступне надбання).

— Відновіть Моніку

1

@BrendanLong Чудові бали. Оцініть дискусію. Щоб було зрозуміло, я думаю, що в обох видах магазинів є переваги та недоліки, я не вірю, що існує лише одна правильна відповідь. Однак я здивований, мабуть, лише троє (чотири, якщо рахувати Vault та Vercity окремо), які використовують SQL, і переважна більшість їх не було, це все.

— Енді

18

Фактично svnвикористовується для використання BDB для сховищ. Зрештою цього позбулися, оскільки він був схильний до поломки.

Інший VCS, який наразі використовує БД (SQLite), є fossil. Він також інтегрує трекер помилок.

Моя здогадка про справжню причину полягає в тому, що VCSes працює з великою кількістю файлів. Файлові системи - це лише інший вид бази даних (ієрархічний, орієнтований на ефективність зберігання CLOB / BLOB). Звичайні бази даних не справляються так добре, тому що немає ніяких причин - файлові системи вже існують.

— Майк Ларсен
джерело

1

BDB точно не вважатиметься надійним - як SQLite - це база даних у процесі. Однак, я думаю, що надійність Oracle / MSSQL / MySQL / Postgres, залежно від способу їх налаштування, не сильно відрізняється від файлових систем. Основна проблема полягає в тому, що RDBMS не побудовані для ієрархічних та графічних структур, з якими VCSes зазвичай працює. І в цьому випадку файлові системи просто виграють.

— Майк Ларсен

3

@Andy: Fossil був створений творцем SQLite. Це насправді не дивно :-)

— Jörg W Mittag

1

@Andy: я б довіряв SQLite набагато більше, ніж Oracle або MSSQL. Не дивно, що це найбільше використовувана база даних SQL з величезним запасом. Крім того, це та, яка переноситься на більшість різних архітектур, кожна з яких має свій власний набір завдань, що робить спільний код неймовірно бездоганним.

— Хав'єр

1

@Javier Я б не довіряв Sqlite стільки, скільки MSSQL або Oracle; як сказав Майк, частина, яка перебуває в процесі роботи, мене лякає, ніби ваша програма помирає, що може залишити вашу БД пошкодженою зараз. З базою даних клієнт / сервер клієнт, що помирає, перериває транзакцію. Не кажучи про неможливість пошкодження баз даних CS, але я вважаю, що це менш ймовірно, ніж поєднання двигуна БД з додатком.

— Енді

5

@Andy, саме для цього потрібні транзакції. Незалежно від того, в який момент ви вбили гарний двигун БД, дана транзакція або вчинена, або ні. Впровадження SQLite атомних комісій ( sqlite.org/atomiccommit.html ) є особливо складним.

— Хав'єр

10

Файлова система - це база даних. Звичайно, не реляційна база даних, але більшість це дуже ефективні сховища ключів / цінностей. І якщо ваші шаблони доступу добре розроблені для зберігання ключових значень (наприклад, формат сховища git), то використання бази даних, ймовірно, не дає значних переваг перед використанням файлової системи. (Насправді, це просто ще один шар абстракції, щоб перешкодити.)
Багато можливостей бази даних - це лише додатковий багаж. Повний текст? Чи має сенс пошуку повного тексту для вихідного коду? Або вам потрібно по-іншому токенізувати? Це також вимагає зберігання повних файлів при кожному перегляді, що є рідкістю. Багато систем управління версіями зберігають дельти між редакціями одного і того ж файлу з метою економії місця, наприклад Subversion і Git (принаймні, при використанні файлів пакету.)
Вимоги до міжплатформних платформ роблять використання бази даних більш складним завданням.

Більшість інструментів контролю версій створені для роботи на декількох платформах. Для централізованих інструментів управління версіями це впливає лише на серверний компонент, але все ще важко покластися на єдиний сервер баз даних, оскільки користувачі Unix не можуть встановити Microsoft SQL Server, а користувачі Windows можуть не бажати встановлювати PostgreSQL або MySQL. Файлова система - найменш поширений знаменник. Однак є кілька інструментів, де сервер повинен бути встановлений на машині Windows, і тому потрібен SQL Server, наприклад SourceGear Vault та Microsoft Team Foundation Server .

Розподілені системи управління версіями все ще роблять це складніше, оскільки кожен користувач отримує копію сховища. Це означає, що кожному користувачеві потрібна база даних для розміщення сховища. Це означає, що програмне забезпечення:
1. Обмежується підмножиною платформ, де існує певна база даних
2. Орієнтований на один резервний сервер бази даних, який є міжплатформним (наприклад, SQLite).
3. Орієнтований на підключений резервний запам'ятовуючий пристрій, щоб можна було використовувати будь-яку базу даних (можливо, включаючи файлову систему).
Більшість розподілених систем управління версіями, тому просто використовуйте файлову систему. Визначним винятком є Veracity SourceGear , який може зберігати в базі даних SQLite (корисно для локальних репозиторіїв) або реляційній базі даних, як SQL Server (можливо, корисний для сервера.) Для їх розміщення в хмарі може використовуватися нереляційний сервер для зберігання даних, як Amazon SimpleDB , але я не знаю, що це правда.

— Едвард Томсон
джерело

Мабуть, так як коментар захисника диявола, мабуть, більшість людей, які задають такі типи запитань "чому б не використовувати базу даних", означають, "чому б не використовувати RDBMS?" з усім дотриманням ACID та іншими проблемами. Той факт, що всі файлові системи вже є власними базами даних, вже відхилено.

— mikebabcock

6

Наскільки я бачив у багатьох пропозиціях, здається, що файли "достатньо хороші" для роботи, щось розумне, беручи до уваги, що наприкінці дня на виході VCSes є також файли.

Є багато компаній, які пропонують задній кінець RDBMS з інтерфейсом svn / git / etc, тому те, що ви просите, в основному вже існує.

— Димитріос Мітріотис
джерело

5

Я б сказав, що це тому, що первинною структурою даних системи управління версіями є DAG, яка відображає бази даних дуже погано. Багато даних також є адресною для вмісту, яка також дуже слабо відображає бази даних.

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

VCS є також споживчим продуктом, крім продукту підприємства. Люди використовують їх у невеликих хобі-проектах. Якщо ви додасте клопоту з встановлення та налаштування сервера баз даних, ви будете відчужувати велику частину цієї частини ринку. Я здогадуюсь, що ви не бачите вдома багато систем Vault та TFS. З тієї ж причини електронні таблиці та текстові процесори не використовують бази даних.

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

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

— Карл Білефельдт
джерело

1

"карти в бази даних дуже погано", але Сейф і TFS роблять саме це. "Цілісність даних не є єдиним питанням системи VCS; вони також стосуються цілісності історії версій, до якої бази даних не дуже хороші". Я не бачу, як зберігання історії версій піддається файлам у базі даних, тим більше, що я назвав продукти, які роблять саме це. "Пошкодження в обох дуже рідкісні, але вони трапляються". Жоден із цих результатів на першій сторінці не говорить про пошкодження бази даних Vault server. Єдиним посиланням, яке навіть говорить про програмне забезпечення Vault, проблема - туалет.

— Енді

"Для всіх цілей і цілей, сховище даних VCS - це база даних." Ну ... це моя суть. Чому б просто не вставити дані в реальну систему баз даних, а не прокручувати власну?

— Енді

2

@Andy Так, це база даних, але не всі бази даних є замінними одна для одної. Кожна база даних має певний погляд на світ (наприклад, SQL БД в основному реалізують реляційну модель). Оскільки в цій відповіді детально, дані, які зберігає ДКС, і спосіб їх використання не відповідають реляційній моделі. Я не впевнений, чи є якийсь NoSQL db кращим, але вони досить нові і ще не підтверджують свою перевагу (для деяких я пригадую повідомлення про серйозні проблеми цілісності). І тоді є всі інші питання на вершині цього.

DAG використовуються лише у DVCS (якщо ви не вважаєте лінійну історію надзвичайно простою DAG, якою вона є, але це насправді не корисна абстракція.) Коли ваша історія лінійна, з монотонно зростаючими наборами змін, база даних SQL має набагато більше сенсу .

— Едвард Томсон

Монотонно зростаючі номери версій не мають великого сенсу для VCSes. Я використав неабияку кількість з них, і ті, з централізованими номерами версій (CVS та SVN - це 2, з якими я найбільше знайомий), як правило, болю зливаються. І навіть ті використовують DAG, коли вони намагаються зробити об'єднання. Тільки тому, що їх представлення на сховищі не засноване навколо, це не означає, що воно не використовується.

— Майк Ларсен

2

Краще відновлення після аварій (найгірший сценарій: ми будемо аналізувати його на око, як у старі часи)
Полегшити відстеження та налагодження таких катастроф, можливо, спричинених помилками в системі VCS.
Зниження кількості залежностей. (Давайте не будемо забувати , один з цих систем обробки на ядро, а інший мав)
Текстовий редактор завжди доступний. (Ліцензії MS SQL Server ... не так вже й багато)

— ZJR
джерело

Ця відповідь просто погана. Єдиний справді справжній момент - зменшення кількості залежностей. Обидві системи резервного копіювання повинні бути нарівні, як ви повинні робити належні резервні копії, налагодження програм DB не є складніше, ніж налагодження програм, які записують файли, а текстовий редактор завжди доступний? Я навіть не знаю, в чому ваша справа, оскільки VCS сам не збирається використовувати текстовий редактор, а там є інші сервери БД (Sqlite, Postgre, MySql тощо), так що якщо ви хотіли Відсутність рішення, підтримуваного DB, не має бути фактором.

— Енді

1

@Andy ... програмісти збираються використовувати текстовий редактор. Ви знаєте, редагування тексту все ще доступне як додаткова функція навіть у вашому улюбленому IDE.

— ZJR

1

@Andy sqliteє єдиною можливою альтернативою текстовим файлам, враховуючи величезну кількість розподілених сценаріїв, якими користуються сучасні DVCS. (idk, можливо, ви, можливо, пропустили "розподілену" частину DVCS). Все інше було б занадто громіздким (конфігурація + брандмауер + ліцензія) або навіть нерозумно поширювалося . Тоді знову зробити найгірший сценарій посмертного виводу на sqlite може виявитися важким.

— ZJR

1

@ ZJR: Я не думаю, що в оригінальному питанні колись було вказано розподілене управління версіями, воно взагалі запитувало про системи управління версіями. Крім того, ваш аргумент текстового редактора є трохи рівним, оскільки багато систем не зберігають лише плоскі текстові файли. Навіть у git є велика кількість бінарних форматів файлів (вільні об’єкти, пакувальні файли тощо), які роблять ваш текстовий редактор непотрібним.

— Едвард Томсон

@ZJR Як редагування коду в текстовому редакторі залежить від резервного сховища VCS? Ви пропонуєте вручну редагувати, скажімо, базу даних SVN? Крім того, моє запитання не обмежується DVCS, тому я не знаю, чому ви на цьому справляєтесь.

— Енді

2

Fossil - це відмінна система управління розподіленою версією (DVCS) і використовує SQLite для зберігання, без файлів із текстовим текстом.

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

Fossil використовує Sqlite як формат файлу програми. У викладі програми PgCon, доктор Річард Хіпп пояснює, які переваги використання sqlite як файлової системи додатків, і робить досить переконливий аргумент переваг використання бази даних як файлової системи.

Друга основна тема полягала в тому, що SQLite слід розглядати як формат файлу додатків - альтернативу винайдення власних форматів файлів або використання ZIPped XML. Заява "SQLite не є заміною для PostgreSQL. SQLite - це заміна нігтів fopen () ”, які (слайд 21). Нарешті, Річард зробив великий акцент на тому, що SQLite піклується про ваші дані (аварійно-безпечний, ACID) use-the-index.com

Тепер доктор Хіпп вирішив питання щодо збереження коду в базі даних

Чому Fossil заснований на SQLite замість розподіленої бази даних NoSQL?

Копальня не заснована на SQLite. Поточна реалізація Fossil використовує SQLite як локальний магазин для вмісту розподіленої бази даних і як кеш для метаінформації про розподілену базу даних, яка попередньо обчислюється для швидкого та простого представлення. Але використання SQLite в цій ролі є деталлю реалізації та не є принциповим для дизайну. Деяка майбутня версія Fossil може скасувати SQLite і замінити набір файлів або базу даних ключа / значення замість SQLite. (Насправді, це навряд чи станеться, оскільки SQLite працює надзвичайно добре у своїй нинішній ролі, але справа в тому, що опускання SQLite з Fossil є теоретичною можливістю.)

— elviejo79
джерело