version-control - 巨大なファイルのバージョン管理システム？

Question

合計約80ギガのファイルの束のスナップショットを作成するための、すばやく、しかしそれほど汚くない方法を探しています。ここでの問題は、ファイルの多くが約1GBの大きさであるということです。

この種のものに最適な無料のバージョン管理システムは何ですか？

ZFSがオプションであることは知っていますが、最初に別のことを試してみたいと思います。

Answer 1

Subversionは、ほとんどの場合、1 GBを超えるファイルを適切な性質で処理しますが、大きな変更が多数ある場合は、差分の生成にしばらく時間がかかると予想されます...

Subversionのベストプラクティスには、大きなファイルに関するセクションがあります。

Subversionの優れた機能は、設計上、処理できるファイルのサイズに制限がないことです。ファイルは、ネットワークの両側にある少量の一定量のメモリを使用して、Subversionクライアントとサーバーの間で双方向に「スムーズに」送信されます。

もちろん、考慮すべき実際的な問題がいくつかあります。キロバイトサイズの範囲のファイル（通常のソースコードファイルなど）について心配する必要はありませんが、大きなファイルをコミットすると、時間とスペースの両方が膨大になる可能性があります（たとえば、数十メガバイトまたは数百メガバイトのファイル）。

まず、Subversionの作業コピーは、バージョン管理されたすべてのファイルの元のコピーを.svn /text-base/領域に保存することを忘れないでください。これは、作業コピーが元のデータセットの少なくとも2倍のディスク容量を使用することを意味します。それを超えて、Subversionクライアントはファイルをコミットするための（現在調整不可能な）アルゴリズムに従います。

。ファイルを.svn/tmp /にコピーします（しばらく時間がかかる場合があり、一時的に余分なディスク領域を使用します））

。tmpfileと元のコピーの間、またはtmpfileと空のファイル（新しく追加された場合）の間でバイナリ差分を実行します。（最終的にネットワーク経由で送信されるデータはごくわずかですが、計算に非常に長い時間がかかる場合があります）

。差分をサーバーに送信してから、tmpfileを.svn /text-base/に移動します

したがって、ファイルのサイズに理論上の制限はありませんが、非常に大きなファイルでは、クライアントが離れるまでかなりの忍耐が必要になる場合があることに注意する必要があります。ただし、CVSとは異なり、大きなファイルがサーバーを無力化したり、他のユーザーに影響を与えたりすることはありませんので、ご安心ください。

Answer 2

あなたは本当にMonotoneを試してみたいかもしれません、ただそれをチェックしてください。あなたはそれであなたが探しているものを見つけるかもしれません。