Почему системы контроля версий по-прежнему в основном защищены файлами?

Похоже, что все больше систем контроля версий все еще используют файлы как средство хранения данных версий. Vault и TFS используют Sql Server в качестве хранилища данных, что, я думаю, было бы лучше как для согласованности данных, так и для скорости.

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

РЕДАКТИРОВАТЬ: я думаю, еще один способ задать мой вопрос: «Почему разработчики VCS катят свою собственную систему структурированного хранения данных вместо того, чтобы использовать существующую?»

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

В качестве вопроса для ответа на вопрос, почему бы не они? Какие преимущества дают «реальные» системы баз данных по сравнению с файловой системой в этом контексте?

Учтите, что контроль версий в основном отслеживает небольшие метаданные и множество различий в тексте. Текст не хранится в базах данных более эффективно, и индексируемость содержимого не будет фактором.

Предположим, что Git (для аргумента) использовал BDB или SQLite DB для своей базы данных для хранения данных. Что может быть более надежным в этом? Все, что может повредить простые файлы, также может повредить базу данных (поскольку это также простой файл с более сложной кодировкой).

От парадигмы программиста не оптимизировать, если это не необходимо, если система контроля версий достаточно быстра и работает достаточно надежно, зачем менять всю конструкцию, чтобы использовать более сложную систему?

Похоже, вы делаете много предположений, возможно, исходя из вашего опыта работы с 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, но я довольно уверен, что Линус Торвальдс понимает файловые системы .

Почему некоторые коммерческие системы контроля версий используют реляционную базу данных?

Скорее всего какая-то комбинация из следующего:

• Некоторые разработчики не хотят писать базы данных.
• Разработчики коммерческих систем контроля версий имеют ограничения по времени и ресурсам, поэтому они не могут позволить себе написать базу данных, когда у них уже есть что-то близкое к тому, что они хотят. Кроме того, разработчики стоят дорого, а разработчики баз данных (например, люди, которые пишут базы данных), вероятно, дороже, так как большинство людей не имеют такого опыта.
• Пользователи коммерческих систем контроля версий с меньшей вероятностью будут заботиться о накладных расходах на настройку и запуск реляционной базы данных, поскольку они уже есть.
• Пользователи коммерческих систем контроля версий с большей вероятностью захотят, чтобы реляционная база данных поддерживала свои данные ревизий, поскольку это может лучше интегрироваться с их процессами (например, резервными копиями).

На самом деле svnиспользуется для использования BDB для хранилищ. Это было в конечном счете избавлено, потому что это было склонно к поломке.

Другой VCS, который в настоящее время использует БД (SQLite) fossil. Он также включает в себя трекер ошибок.

Я предполагаю, что настоящая причина в том, что VCS работают с большим количеством файлов. Файловые системы - это просто еще один вид базы данных (иерархический, ориентированный на эффективность хранения CLOB / BLOB). Обычные базы данных не справляются с этим хорошо, потому что нет никаких причин - файловые системы уже существуют.

1. Файловая система - это база данных. Конечно, это не реляционная база данных, но большинство из них являются очень эффективными хранилищами ключей / значений. И если ваши шаблоны доступа хорошо спроектированы для хранилища значений ключей (например, формата репозитория git), то использование базы данных, вероятно, не дает существенных преимуществ по сравнению с использованием файловой системы. (На самом деле, это просто еще один уровень абстракции, чтобы мешать.)

2. Многие функции базы данных просто дополнительный багаж. Полнотекстовый поиск? Имеет ли смысл полнотекстовый поиск для исходного кода? Или вам нужно по-другому токенизировать? Это также требует, чтобы вы сохраняли полные файлы при каждой ревизии, что необычно. Многие системы контроля версий хранят дельты между ревизиями одного и того же файла для экономии места, например, Subversion и Git (по крайней мере, при использовании файлов пакета).

3. Кроссплатформенные требования усложняют использование базы данных.

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

   Распределенные системы контроля версий еще более усложняют эту задачу, поскольку каждый пользователь получает копию хранилища. Это означает, что каждому пользователю нужна база данных для размещения репозитория. Это подразумевает, что программное обеспечение:

   1. Ограничено подмножеством платформ, где существует конкретная база данных
   2. Предназначен для одной кросс-платформенной базы данных (например, SQLite).
   3. Предназначен для подключаемого хранилища, чтобы можно было использовать любую базу данных, которую они пожелают (возможно, включая файловую систему).

   Поэтому большинство распределенных систем контроля версий просто используют файловую систему. Примечательным исключением является SourceGear Veracity , который может хранить в базе данных SQLite (полезной для локальных репозиториев) или реляционной базе данных, такой как SQL Server (возможно, полезной для сервера). Их размещаемое в облаке предложение может использовать нереляционную систему хранения, такую ​​как Amazon SimpleDB. , но я не знаю, чтобы это было правдой.

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

Есть много компаний, которые предлагают СУРБД с интерфейсом svn / git / etc, так что то, о чем вы просите, в основном уже существует.

Я бы сказал, это потому, что основной структурой данных системы контроля версий является группа обеспечения доступности баз данных, которая очень плохо отображает базы данных. Большая часть данных также является адресно-зависимой, что очень плохо отображает базы данных.

Целостность данных - не единственная забота VCS, они также касаются целостности истории версий , в которой базы данных не очень хороши. Другими словами, когда вы извлекаете версию, вам нужно не только убедиться, что версия не имеет текущих недостатков, но также и то, что ничего за всю ее историю не было тайно изменено.

VCS также является потребительским продуктом в дополнение к корпоративному продукту. Люди используют их в небольших проектах для одного человека. Если вы добавите хлопоты по установке и настройке сервера базы данных, вы собираетесь оттолкнуть большую часть этой части рынка. Я предполагаю, что вы не видите много установок Vault и TFS дома. По той же причине электронные таблицы и текстовые процессоры не используют базы данных.

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

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

• Лучшее аварийное восстановление (наихудший сценарий: мы разберем его на глаз, как в старые времена)

• Облегчение отслеживания и отладки таких аварий, возможно, вызванных сбоями в системе VCS.

• Снижение количества зависимостей. (давайте не будем забывать , один из этих систем обработки на ядро, а другой должен был)

• Текстовый редактор всегда доступен. (MS SQL Server лицензий ... не так много)

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 является теоретической возможностью.)