なぜソース管理システムのほとんどがまだファイルでバックアップされているのですか？

バージョンデータを保存する手段としてファイルを使用するソース管理システムが増えているようです。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のような最新のバージョン管理システムがそれらのように動作すると仮定しても、ほとんど意味がありません。

リレーショナルデータベースは、単一目的のデータベースよりも効率的です。

どうして？リレーショナルデータベースは非常に複雑で、単一目的のデータベースほど効率的ではありません。私の頭の上のいくつかの違い：

• とにかく同時に複数のコミットを行うことはできないため、バージョン管理システムは複雑なロックを必要としません。
• 分散バージョン管理システムは、ローカルデータベースがリポジトリの完全なコピーであるため、スペース効率が非常に高い必要があります。
• バージョン管理システムで必要なのは、特定の2つの方法（作成者、リビジョンID、フルテキスト検索など）でデータを検索することだけです。著者/リビジョンIDの検索を処理できる独自のデータベースを作成するのは簡単であり、私が試したどのリレーショナルデータベースでも全文検索はそれほど高速ではありません。
• バージョン管理システムは、複数のプラットフォームで動作する必要があります。これにより、インストールしてサービスとして実行する必要があるデータベース（MySQLやPostgreSQLなど）を使用することが難しくなります。
• ローカルマシンのバージョン管理システムは、何かを実行しているとき（コミットなど）にのみ実行する必要があります。コミットしたい場合に備えて、 MySQLのようなサービスを常に実行したままにしておくのは無駄です。
• ほとんどの場合、バージョン管理システムは履歴を削除するのではなく、履歴に追加するだけです。これにより、最適化が異なり、整合性を保護する方法が異なる場合があります。

リレーショナルデータベースの方が安全です

繰り返しますが、なぜですか？データはファイルに保存されるため、gitやMercurialなどのバージョン管理システムにはアトミックコミットはありませんが、そうするように思われます。リレーショナルデータベースは、データベースをファイルとして保存します。ここで注目に値するのは、CVS がアトミックコミットを行わないことですが、それはおそらく、リレーショナルデータベースを使用していないからではなく、暗黒時代からのものだからです。

また、データがデータベースに格納されると、データを破損から保護するという問題もあります。その答えは同じです。ファイルシステムが破損している場合、使用しているデータベースは関係ありません。ファイルシステムが破損していない場合、データベースエンジンが破損している可能性があります。なぜバージョン管理データベースがリレーショナルデータベースよりもこの傾向があるのか​​はわかりません。

分散型バージョン管理システム（gitやMercurialなど）は、一元化されたバージョン管理よりもデータベースの保護に適していると主張します。どのクローンからでもリポジトリ全体を復元できるからです。そのため、中央サーバーがすべてのバックアップとともに自発的に燃焼した場合git init、新しいサーバーで実行し、次に開発者のマシンgit pushから実行することで復元できます。

車輪の再発明は悪い

ストレージの問題にリレーショナルデータベースを使用できるからといって、そうすべきだとは限りません。なぜリレーショナルデータベースの代わりに構成ファイルを使用するのですか？リレーショナルデータベースにデータを保存できるのに、なぜファイルシステムに画像を保存するのですか？すべてをリレーショナルデータベースに保存できるのに、コードをファイルシステムに保持するのはなぜですか？

「持っているのがハンマーだけなら、すべてが釘のように見えます。」

また、オープンソースプロジェクトは、商業プロジェクトと同じ種類のリソース制約がないため、都合の良いときにいつでも車輪を再発明する余裕があるという事実もあります。データベース作成のエキスパートであるボランティアがいる場合、それらを使用してみませんか？

リビジョン管理システムの作成者が何をしているのかを信頼できる理由については、他のVCSについては話すことはできませんが、Linus Torvalds はファイルシステムを理解していると確信しています。

なぜ一部の商用バージョン管理システムはリレーショナルデータベースを使用するのですか？

ほとんどの場合、以下のいくつかの組み合わせ：

• 一部の開発者は、データベースを書きたくありません。
• 市販のバージョン管理システムの開発者には時間とリソースの制約があるため、既に望んでいるものに近いデータベースを作成する余裕はありません。また、開発者は高価であり、ほとんどの人はそのような経験がないため、データベース開発者（データベースを作成する人など）はおそらくより高価です。
• 商用バージョン管理システムのユーザーは、リレーショナルデータベースを既に設定しているため、セットアップと実行のオーバーヘッドを気にしません。
• 商用バージョン管理システムのユーザーは、リビジョンデータをバックアップするリレーショナルデータベースが必要になる可能性が高くなります。これは、プロセスとの統合性が向上する可能性があるためです（バックアップなど）。

svnリポジトリにBDBを使用するために実際に使用されます。これは、破損しやすいため、最終的に削除されました。

現在DB（SQLite）を使用している別のVCSはfossilです。また、バグトラッカーも統合されています。

本当の理由での私の推測は、VCSは多くのファイルで動作するということです。ファイルシステムは、単なる別の種類のデータベースです（階層的で、CLOB / BLOBストレージの効率に焦点を当てています）。通常のデータベースは、ファイルシステムがすでに存在する理由がないため、うまく処理しません。

1. ファイルシステムはデータベースです。もちろん、リレーショナルデータベースではありませんが、ほとんどは非常に効率的なキー/値ストアです。また、アクセスパターンがキーと値のストア（たとえば、gitリポジトリ形式）向けに適切に設計されている場合、データベースを使用しても、ファイルシステムを使用するよりも大きな利点はおそらくないでしょう。（実際、邪魔になるのは抽象化の別のレイヤーにすぎません。）

2. データベースの機能の多くは、単なる超過手荷物です。全文検索？全文検索はソースコードにとって意味がありますか？または、それを別の方法でトークン化する必要がありますか？また、すべてのリビジョンで完全なファイルを保存する必要がありますが、これは一般的ではありません。多くのバージョン管理システムは、スペースを節約するために、同じファイルのリビジョン間の差分を保存します。たとえば、SubversionとGit（少なくとも、パックファイルを使用する場合）。

3. クロスプラットフォームの要件により、データベースの使用はより困難になります。

   ほとんどのバージョン管理ツールは、複数のプラットフォームで実行するように構築されています。集中型バージョン管理ツールの場合、これはサーバーコンポーネントにのみ影響しますが、UNIXユーザーはMicrosoft SQL Serverをインストールできず、WindowsユーザーはPostgreSQLまたはMySQLをインストールすることを望まない可能性があるため、単一のデータベースサーバーに依存することは依然として困難です。ファイルシステムは、最も一般的な分母です。ただし、サーバーをWindowsマシンにインストールする必要があるため、SourceGear VaultやMicrosoft Team Foundation Serverなど、SQL Serverを必要とするツールがいくつかあります。

   すべてのユーザーがリポジトリのコピーを取得するため、分散バージョン管理システムでは、これがさらに困難になります。これは、すべてのユーザーがリポジトリを配置するデータベースを必要とすることを意味します。これは、ソフトウェアが次のことを意味します。

   1. 特定のデータベースが存在するプラットフォームのサブセットに限定されます
   2. クロスプラットフォームの単一のデータベースバックエンド（SQLiteなど）を対象としています。
   3. プラグ可能なストレージバックエンドを対象とするため、希望するデータベース（ファイルシステムを含む可能性がある）を使用できます。

   したがって、ほとんどの分散バージョン管理システムは、ファイルシステムを使用するだけです。注目すべき例外は、SourceGearののある信憑性のSQLiteデータベース（ローカルリポジトリに便利）やSQL Serverなどのリレーショナルデータベースに保存することができ、（サーバーの可能性が便利。）彼らのクラウドホスト型の提供が可能アマゾンのSimpleDBなどの非リレーショナルストレージバックエンドを使用します、しかしこれが真実であるとは知らない。

私が多くの製品で見た限りでは、ファイルはジョブに「十分」であるように思えます。1日の終わりにVCSesの出力もファイルであることを考慮すると、妥当なものです。

svn / git / etcインターフェースを備えたRDBMSバックエンドを提供している会社はたくさんあります。したがって、あなたが求めているものは基本的にすでに存在しています。

これは、バージョン管理システムの主要なデータ構造がDAGであり、データベースへのマッピングが非常に悪いためだと思います。また、多くのデータはコンテンツアドレス指定可能であり、データベースへのマッピングも非常に不十分です。

データの整合性はVCSの唯一の関心事ではなく、バージョン履歴の整合性にも関心があります。データベースはあまり得意ではありません。言い換えると、バージョンを取得するとき、そのバージョンに現在の欠陥がないことを確認するだけでなく、その履歴全体で何も不正に変更されていないことも確認する必要があります。

VCSは、エンタープライズ製品に加えて消費者製品でもあります。人々は小さな、一人の趣味のプロジェクトでそれらを使用します。データベースサーバーのインストールと構成の手間を追加すると、市場のその部分の多くを疎外することになります。自宅に多くのVaultとTFSのインストールが表示されないのではないかと思います。これは、スプレッドシートやワードプロセッサがデータベースを使用しないのと同じ理由です。

また、これはDVCSのより多くの理由ですが、データベースを使用しないことで非常にポータブルになります。データベースサーバープロセスを構成しなくても、ソースツリーをサムドライブにコピーして任意のマシンで再利用できます。

これまでコミット時に破損などとして、VCSは、同時アクセスを防止するためのデータベースとまったく同じ技術を使用して、トランザクションがアトミックにする、などの両方で破損のは非常にまれですが、彼らはない が起こります。すべての意図と目的において、VCSデータストアはデータベースです。

• 災害復旧の改善（最悪のシナリオ：昔のように目で解析します）

• おそらくVCSシステムの障害によって引き起こされるこのような災害の追跡とデバッグを容易にします。

• 依存関係の数を減らします。（これらのシステムの1つがカーネルを処理しており、もう1つが想定されていたことを忘れないでください）

• テキストエディタは常に利用可能です。（MS SQL Serverのライセンス...それほどではありません）

Fossilは優れた分散バージョン管理システム（DVCS）であり、ストレージにSQLiteを使用し、プレーンテキストファイルは使用しません。

バグ追跡、Wiki、そして実際に配布されていることを本当に気に入っています。本当にオフラインで作業してバグを修正できるということです。

Fossilは、アプリケーションファイル形式としてSqliteを使用します。PgConの基調講演で、Richard Hipp博士は、sqliteをアプリケーションファイルシステムとして使用する利点について説明し、データベースをファイルシステムとして使用する利点についてかなり説得力のある議論をしています。

2番目の主要なトピックは、SQLiteをアプリケーションファイル形式と見なすべきであるということです。これは、独自のファイル形式を発明したり、ZIPで圧縮されたXMLを使用する代わりになります。「SQLiteはPostgreSQLに置き換わるものではありません。SQLiteは、fopen（）”の代わりになるものです（スライド21）。最後に、Richardは、SQLiteがデータ（クラッシュセーフ、ACID）を処理するという事実に多くの重点を置いていますuse-the-index.com

現在、Hipp博士は、データベースにコードを保存することに関する懸念に対処しています。

• Fossilが分散NoSQLデータベースではなくSQLiteに基づいているのはなぜですか？

FossilはSQLiteに基づいていません。Fossilの現在の実装では、SQLiteを分散データベースのコンテンツのローカルストアとして、および迅速かつ簡単に表示できるように事前計算された分散データベースに関するメタ情報のキャッシュとして使用しています。ただし、この役割でのSQLiteの使用は実装の詳細であり、設計の基本ではありません。Fossilの将来のバージョンでは、SQLiteを廃止し、SQLiteの代わりにファイルの山またはキー/値データベースを置き換える可能性があります。（実際には、SQLiteが現在の役割で驚くほどうまく機能するため、これは起こりそうにありませんが、ポイントはFossilからSQLiteを省略することは理論的な可能性です。）