1

(これは私の最初の投稿なので、優しくしてください) 大きなバイナリのバージョン管理として Subversion を使用しています。1 時間ごとに更新する約 2.5 ギガのバイナリがあります。私は毎日、約 400 メガバイト相当の差額を受け取ります。一部のファイルは PE ですが、主に圧縮ファイルであり、適切な差分を取得するのが困難です。私のクライアントの ".svn" フォルダは毎日増え続けており、この増加に対応するためのスペースがクライアントにありません。

このサイズは、クライアント上の subversions の元のコピーが原因です (リポジトリは非常に小さいです)。GIT や Mercurial などの分散型バージョン管理では、クライアントにある種のリポジトリが保存されますが、そのためのスペースがありません。差分を実際に作成することはありません。ヘッドまたは特定のバージョンを更新するだけです。したがって、クライアント側の元のコピーの速度の利点は、私には何の違いもありません。

だから私は CVS を使うつもりです。

  1. 成熟した

  2. クライアント側の光（元のコピーではなく、私にとって非常に重要です）

  3. サーバーベースのアーキテクチャです

  4. オープンソース、私は貧乏です。

バックアップ ソリューションなど、まったく別のものを使用する必要がありますか? これらの要件を満たす CVS 以外の別のバージョン管理はありますか?

4

4 に答える 4

1

大きなファイルを使用する Mercurial は、アシスタントを使用する git-annex に似ています。 http://kiln.stackexchange.com/questions/4846/how-do-i-use-the-mercurial-largefiles-extension DVCS の D を壊すため、「最後の手段の機能」と適切にラベル付けされています (git と同様)。 -annex)、それはあなたが求めているものです。それは正常に動作し、Fog Creek (このサイトを一次概算で紹介している人々) によってサポートされています。

私は CVS グーラグで 10 年間過ごしました。検討したことには敬意を表しますが、あなたはそこに行きたくありません。コミット中に誰かが初めて ctrl-C を押して、レポを半分コミットした状態のままにし、,vファイルを選択してダメージを元に戻そうとしているときに、自分自身をキックしたいと思うでしょう。-kbファイル名に UTF-8 を入れることを覚えていない、または (IIRC) がファイル名にスペースを入れようとすることを覚えていないのに、誰かが初めて UTF-8 コンテンツを欲しがったとき、あなたは CVS を呪うでしょう。

于 2013-05-27T13:49:08.293 に答える
0

クライアントがファイルの任意の履歴バージョンをフェッチする機能を備えている必要があるかどうかが明確ではないため、質問は少し意味がありません。そのため、要件に合う場合と合わない場合がある一連のオプションを提供しようとしています。これが少なくともあなたに何らかのヒントを提供できることを願っています...

だからここに行きます：

  • git-annex実際にクライアントに保持することなく、Git を使用して巨大なファイルのセットを管理できるようにするソリューションです。
  • Sparkleshareは「非独占的な Dropbox」です。
  • プレーンrsyncは、データをクライアントに非常に効果的にプルするために使用される場合があります。

  • rdiff-backup前者のバリエーションとして使用される可能性があります。一般的にはそのようにrsync動作しますが、同期されているディレクトリの過去の状態を表す任意の数の「デルタ」を保持できるため、そのような状態が抽出/ロールバックされる可能性があります。古いデルタは自由に削除できます。

    これは と組み合わせることができますrsync:rdiff-backupはサーバー上で使用され、それによって管理される実際のコピーは を介し​​てクライアントに提供されますrsync。ロールバックが必要な場合は、別のバージョンがサーバーに復元され、クライアントは を使用してそれを取得しますrsync。

  • Bittorrent サーバーとクライアント: このプロトコルはチャンクを使用してファイルを転送するため、バイナリへの変更がある程度ローカライズされている場合、これは問題なく機能する可能性があります。
于 2013-05-27T12:59:11.853 に答える