私たちのショップは常にディスク容量が不足しています。これは、開発者と経営陣から、デバッグに非常に役立つすべてのナイトリー ビルドを保持するように指示されているためです。
通常、各ビルドにはほとんど変更がありません。ただし、ほとんどすべてのファイルはビルドごとに異なります。これは、コンパイラとリンカーがオブジェクトと実行可能ファイルに日付/タイム スタンプ (およびバージョン) を挿入するためです。
問題は、「重複ファイルをマージする」だけでなく、「同様のファイルをマージする」こともできるファイルシステムを知っている人はいますか? (コードが変更されても、主要なヘッダーやライブラリが変更されない限り、実行可能ファイルへの影響は一般的に小さいです。)
従来のバージョン管理システムではないのはなぜですか?
これまでで最初のビルドを開始し、その上で他のビルドを連続してコミットします。ファイルが重複している場合、デルタは作成されません。変更がある場合は、変更のみが保存されます。
それはあなたが求めたものではありませんか？
OpenSolaris と ZFS。
一般的に、これらのタイプのトピックに関する私の意見は、「不十分な管理上の決定から抜け出す方法をコーディングしようとしないでください」です。
多くの古いビルド ファイルを保持したい場合は、「マンアップ」してスペースを購入します (ディスク スペースは安価です)。
ディスクを購入したくない場合は、利用可能なスペース内に収まるように、適切な数のビルドを選択してください。
それほど難しい問題ではありません。
このパスを最も遠くまでたどるのは、ドライブが利用可能な場合はドライブで「ディスク圧縮」を有効にすることです。これは、OS によって処理され、追加のアプリとそれに伴うサポートを必要としないためです。確かに、パフォーマンスへの影響はわずかですが、単純です。
重要なことのために「開発」ジュースを保存します。:-)
これは貧弱な解決策ですが、ビルド ストレージが主要な経済的決定である場合、この答えは正当化されると思います。:)
第 1 に、この種の複雑なファイル参照を新しいストレージに支払うよりも安価に実行できるまったく新しいストレージ/ソース管理システムが見つかる可能性はほとんどありません。
過去 2 か月分のビルドを高価なストレージ (RAID など) に保管しておき、アーカイブ用の安価なストレージ (他の誰かが言及した 1 TB USB ドライブなど) を手に入れるのはどうでしょうか。
スケジュールされたタスクとして毎晩実行され、すべてのファイルを 2 か月以内にアーカイブ ドライブに移動する、単純な小さなコンソール アプリを作成します。
cramfs はこれを行うと思いますが、cramfs イメージ (読み取り専用) を作成するのは頭痛の種かもしれません。
うーん..ビルドをアーカイブする必要があるのはなぜですか? 以前のソース管理されたバージョンからビルドを再作成するのは簡単なことではないでしょうか?
ほとんどの場合、透過的な圧縮を備えたファイルシステムまたはボリューム マネージャーが必要です。パフォーマンスは当然損なわれますが、軽い圧縮を使用する場合はそれほど問題にはなりません。
新しいファイル管理スキームをインストールして維持する労力のほんの一部で、ハード ドライブを追加購入します。私は昨夜 Frys にいましたが、彼らは 1 TB の外付けドライブを $100 で売っていました。それは USB ドライブです。プラグを差し込むだけです。いっぱいになったら、別のドライブを購入してください。開発者として言えば、あなたのショップが本当にビルドを無期限に保持したいと思っているとしたら、私は驚きます。ナイトリー ビルドの価値は、数か月後には低くなると思います。
これは洗練されたソリューションではありませんが、費用対効果が高くなる可能性があります。
重複ファイルを削除するためのアプリケーションを使用する必要があると思います。これは、より良い解決策になります。私は、重複ファイルを削除するソフトウェアを使用しており、重複ファイル ファインダー 2009 と呼ばれています。