たくさんのバイナリファイルを保存する上でSubversionはどの程度優れていますか？
数GBのドキュメントを配置する場所を探しています（主に.docおよび.xls）。私のチームには、作成したドキュメントを管理するためのSubversionサーバーが既にセットアップされているので、可能であればそれを使用したいと思います。 Subversionはこれらすべての余分なものをどれだけうまく処理しますか？そのほとんどはレガシー情報であり、バージョンは1つしかありませんが、いくつかのドキュメントが更新される可能性があります。
SVNは特に多くのビッグバイナリファイルに対応していないという警告が表示されました。後で削除してもリポジトリの履歴には常に表示されるため、機能するかどうかを確認するのには注意が必要です。
代替案はありますか？ドキュメントにコメントやタグを付ける機能が必要ですが、SVN（または同様の）のドキュメントのURLと組み合わせたDeliciousのようなサービスを使用できます。
後でバイナリの差分については、上で述べたようにほとんど変更されないので、それほど心配していません。少し面倒でも大丈夫です。SharePointよりも悪くはありません。
多くの大きなバイナリファイルと、多数のバイナリファイルとの間には違いがあります。
私の経験では、SVNは数百メガバイトの個別のバイナリファイルで問題ありません。私が見た唯一の問題は、ギガバイト程度の個々のファイルで発生し始めます。不可解で未知の理由で操作が失敗し、SVNがネットワーク関連の問題を処理できない可能性があります。
マージ機能の欠如と、バイナリファイルをデルタとして効率的に格納できないことが多いという事実（SVNはデルタを使用できます）を除いて、バイナリファイルの数に関連するSVNの問題については知りません。
そう;
- 1000 1MBファイル=細かい。
- 100 MBファイル= 100
- 10 100MBファイル=細かい
- 1> 1000MBファイル=良い考えではありません。
あなたのドキュメントのサイズが素晴らしいカテゴリの1つに収まることを願っています:)
前の会社では、Subversionを保存するようにセットアップしましたCADファイル。最大100 MBのファイルがSubversionに保存されていました。多くの人が大きなファイルをSubversion Webサーバーに「追加」するとボトルネックになる可能性があります。ただし、増分コミット完全に良かった。
Subversionは「バイナリデルタ」を保存しました。実際、サーバー側では、バイナリファイルとテキストファイルは「デルタ」の格納でまったく同じように扱われます。ページの「バイナリデルタエンコーディングの改善」セクションを確認してください http://Subversion.tigris.org/svn_1.4_releasenotes.html 。明示的に「Subversionはxdeltaアルゴリズムを使用してバイトの文字列 "間の違いを計算します（「文字」の文字列ではありません）。
実験のために、CAD（CATIAパーツファイル）の10バージョンを保存しました。各バージョンでマイナーな変更を行い、サーバー側のリポジトリサイズを確認しました。合計サイズは約1.2倍でした。約10リビジョン（x-は元のファイルサイズです）。
Svn：needs-lockプロパティを忘れずに設定してください。私の経験では、「自動小道具」を使用して、ファイル拡張子に基づいてsvn：needs-lockを設定するのが最善の方法です。
バージョン管理を必要とする非常に大きな設計/コンサルティングジョブを行ったため、このために Subversion クライアントを構築しました。私たちはそれで問題がなかった。
ファイルが更新される頻度によって異なります。バイナリファイルのマージについては何もできません。そのため、競合が発生するたびに痛みが生じます。それ以外の場合は、単なる格納と取得であり、テキストほど良くありませんが、それでも問題なく処理されます。
私は個人的にそのようなタスクにMercurialを使用しています。私は数百のメディアのギグを保存するためにそれを使用しました。はい、ディスク容量を消費しますが、ディスク容量は安価です。 Mercurialを使用すると、配布されるという利点も得られるため、「チェックアウト」、つまりMercurialで知られているようにクローンを作成すると、スナップショットだけでなく、リポジトリ全体を取得できます。サーバーが停止した場合でも、サーバーは稼働しています。