38

.doc数 GB のドキュメント (主にと)を置く場所を探してい.xlsます。私のチームでは、作成したドキュメントを管理するために既に Subversion サーバーをセットアップしているので、可能であればそれを使用したいと考えています。Subversion は、この余分なものすべてをどの程度うまく処理できるでしょうか? そのほとんどは古い情報であり、1 つのバージョンしかありませんが、いくつかのドキュメントが更新される可能性があります。

SVN は大量の大きなバイナリ ファイルに特に適しているわけではないという警告を受けました。後で削除してもリポジトリの履歴に常に残るため、機能するかどうかを確認するのは慎重です。

代替案はありますか？ドキュメントにコメントしたり、タグを付けたりする機能が必要ですが、SVN (または同様のもの) のドキュメントの URL と組み合わせて、Delicious のようなサービスを使用できます。

上 で述べたように、バイナリはあまり変わらないので、バイナリの差分についてはあまり心配していません。少し手間がかかっても問題ありません。SharePoint よりも悪くはありません。

4

7 に答える 7

41

以前の会社では、CAD ファイルを保存するために Subversion をセットアップしていました。最大 100 MB のファイルが Subversion に保存されました。多くの人が大きなファイルを Subversion Web サーバーに「追加」すると、ボトルネックになる可能性があります。ただし、増分コミットは完全に問題ありませんでした。

Subversion は「バイナリ デルタ」を保存しました。実際、サーバー側では、バイナリ ファイルとテキスト ファイルは「デルタ」の格納においてまったく同じように扱われます。ページhttp://subversion.tigris.org/svn_1.4_releasenotes.htmlの「バイナリ デルタ エンコーディングの改善」セクションを確認してください。「Subversion は xdelta アルゴリズムを使用して、バイト文字列間の差異を計算します」(「文字列」ではなく)と明示的に述べています。 ')。

実験用に、10 バージョンの CAD (CATIA パーツ ファイル) を保存しました。各バージョンの一部に小さな変更を加えてから、サーバー側のリポジトリのサイズを確認しました。合計サイズは、約 10 回のリビジョンで約 1.2x でした (x - 元のファイル サイズ)。

svn:needs-lock プロパティを忘れずに設定してください。私の経験では、「auto props」を使用して、ファイル拡張子に基づいて svn:needs-lock を設定するのが最善の方法です。

于 2009-02-14T03:56:27.507 に答える
34

多数の大きなバイナリ ファイルと多数のバイナリ ファイルには違いがあります。

私の経験では、SVN は数百メガバイトの個々のバイナリ ファイルで問題ありません。私が見た唯一の問題は、約 1 GB 程度の個々のファイルで発生し始めました。不可解で不明な理由で操作が失敗します。おそらく、SVN はネットワーク関連の問題を処理できません。

マージ機能の欠如と、バイナリファイルをデルタとして効率的に保存できないことが多いという事実を超えて、バイナリファイルの数に関連するSVNの問題を認識していません（SVNはデルタを使用できます）。

そう;

  • 1000 個の 1MB ファイル = 問題ありません。
  • 10MB のファイル 100 個 = 問題ありません
  • 100MB のファイル 10 個 = 問題ありません
  • 1 >1000MB ファイル = 良い考えではありません。

あなたのドキュメントのサイズが細かいカテゴリの1つに収まることを願っています:)

于 2009-02-11T20:39:26.823 に答える
3

バージョン管理が本当に必要な本当に大きな設計/コンサルティングの仕事をしたので、私たちはまさにこれのためにSubversionクライアントを構築しました。問題はありませんでした。

于 2009-02-14T11:49:39.613 に答える
1

ファイルの更新頻度によって異なります。バイナリ ファイルのマージについては何もできないため、競合が発生するたびに苦労します。それ以外の場合は、単なる保存と検索であり、テキストほど良くはありませんが、それでも問題なく処理できます。

于 2009-02-11T20:43:06.207 に答える
0

私は個人的にそのようなタスクに Mercurial を使用しています。数百ギガのメディアを保存するために使用しました。はい、ある程度のディスク容量を占有しますが、ディスク容量は安価です。Mercurial では、配布されているという利点も得られるため、「チェックアウト」、または Mercurial で知られているクローンを実行すると、スナップショットだけでなく、リポジトリ全体を取得できます。サーバーが停止した場合でも、まだビジネスを継続できます。

于 2009-02-11T20:53:39.207 に答える
-4

私が見たところ、Git は Subversion に比べて非常に高速であり、Mercurial よりも少しだけ速いと聞いています。ただし、大規模な、または多数のバイナリ ファイルで具体的にテストしたことはありません。

そうは言っても、Git が変更を追跡する方法は、バイナリ ファイルを処理するのに非常に効率的だと思います。

これは確かに言えます。Git に慣れたら、Subversion に戻ることはありません。Subversion リポジトリを使用する必要があるときは、git-svn を介して Git を使用しています。このようにして、分散バージョン管理のすべての利点を得ることができますが、コミットを中央の Subversion リポジトリにプッシュするための非常に優れたサポートも引き続き利用できます。

于 2009-02-11T22:05:55.307 に答える
-5

それを Subversion に保存すると、かなりのスペースが必要になります。Subversion は、テキスト ファイルを格納する方法のように、デルタを介してバイナリ ファイルを格納しません。ハードドライブとリポジトリに大量のバイナリファイルを保存するのと同じくらいのスペースが必要になるでしょう。

サーバー側の tiddlywiki を使用して、Subversion 内のドキュメントへの URL を保存できる場合があります。

ほとんどが .doc および .xls ファイルである場合は、Microsoft の Sharepoint もあります。

于 2009-02-11T20:39:43.733 に答える