14

私はいくつかの分岐戦略 (私たちは小さなグループなので、機能ごと、おそらく開発者ごとに分岐を作成する) について考えていて、誰かが何か問題を経験したかどうか疑問に思っていました. ブランチを作成すると多くのスペースが必要ですか?

4

2 に答える 2

15

前回見たとき、TFS はコピー オン ライトを使用しています。つまり、ファイルを変更するまでディスク領域を増やすことはありません。変更が必要になるまでシンボリックリンクを使用するようなものです。

于 2009-10-06T17:03:33.163 に答える
6

ジェームズは基本的に正しいです。より完全な答えを得るには、2006 年にさかのぼるBuckの投稿から始める必要があります。

ローカル バージョン テーブルの新しい行ごとに、約 520 バイトが追加されます (新しく追加された項目を取得するワークスペースごとに 1 つの行が追加され、サイズはローカル パス列によって支配されます)。新しく追加されたアイテムを取得するワークスペースが 100 ある場合、データベースは 52 KB 増加します。平均サイズ (ソース ファイル、バイナリ、イメージなどの混合) の 1,000 個の新しいファイルを追加し、それらを取得する 100 個のワークスペースがある場合、バージョン管理データベースは約 112 MB (60 KB * 1,000 + 520 * 1,000 * 100) 増加します。 .

分岐したアイテムはファイルの内容を複製しないため、60KB の数字は省略できます。(これは完全に「コピーオンライト」ではありません。James -- O(1) で分岐すると私が信じている git のようなシステムに対して、O(N) 量のメタデータを分岐操作自体の間に計算して保存する必要があります -- しかし、新しいアイテムが、編集されるまで、ソース アイテムと同じ tbl_Content のレコードを指していることは正しいです)。それは私たちに520 * num_workspaces * files_per_workspace要因だけを残します。MS ドッグフード サーバーでは、tbl_LocalVersion に 20 億行ほどありますが、自称小規模グループでは、まったく無視できるはずです。

Buck のブログで言及されていないのは、マージ履歴です。ブランチを多用するワークフローを採​​用し、いくつかの開発サイクルを続けると、tbl_MergeHistory は tbl_LocalVersion とほぼ同じ大きさになる可能性があります。繰り返しになりますが、小規模なチームのレーダーに登録されるとは思えませんが、大規模なインストールでは、何億行も簡単に収集できます。つまり、nvarchar(260) フィールドがないため、各行ははるかに小さくなっています。

于 2009-10-09T03:04:39.087 に答える