これらのメソッドのいずれかを使用するように Subversion を設定するのではなく、ファイルをリポジトリに配置するときに使用するメソッドを指定します。そして、「メソッド」とは、あなたが言及した4つのいずれかを意味するのではなく、単に「インポート」または「コミット」することを意味します。新しいメソッドを保存するたびに、選択したメソッドについてSubversionに伝え続ける必要がありますそのファイルのリビジョンをリポジトリに追加します。
パフォーマンス チューニング Subversionを参照してください。
そこの説明からわかるように、「方法 1」を使用して tar に圧縮してから import を使用するには、自分ですべてのバイナリ ファイルを .tar ファイルに圧縮し、Subversion の import コマンドを使用してファイルをリポジトリに追加します。
また、注意点として、インポート コマンドはファイルを以前のリビジョンへのデルタとしてではなく、新しいファイルとして保存するため、大きなファイルへの変更がほとんどコミットされていない場合、時間効率は良くなりますが、スペース効率は良くない可能性があります。
Subversion 自体は、コミットとインポートのみを行います。コミットは既存のファイルの新しいリビジョンであり、一連のデルタ (または新しいファイルの最初のリビジョン) として保存され、インポートは単なる新しいファイルです。それ以外はすべて自分で行う必要があります。
バイナリ ファイルがときどき変更されるだけの場合は、さらに調べる価値があるかもしれませんが、定期的に変更される場合は、Subversion を通常どおりコミット コマンドで使用することをお勧めします。
また、バイナリ ファイルに関する一般的なアドバイスは、バイナリ ファイルの代わりに、可能であればそれらのバイナリ ファイルを生成するソース コードを保存し、ツールを再実行して実際のバイナリ ファイルを再現することです。 . バイナリ ファイルの複製に時間や容量が必要な場合にのみ、問題のバイナリ ファイルも保存します。
バイナリ ファイルには、実際には比較に適していないという問題があります。そのため、開発者 a と b の両方が最新バージョンを取得し、開発者 b が同じことを試みる前に開発者 a が新しいリビジョンをコミットすると、ある種の競合が発生します。開発者 B には、自分で変更を把握しようとする以外に選択肢がない場合があります。
編集：COMMITとIMPORTの意味を強調させてください。
主な違いは、COMMIT は、既にファイルがリポジトリにあると仮定して、作業コピー内のファイルを以前のリポジトリ バージョンと比較しようとし、変更のみを保存することです。これらの違いを解決するには、時間とメモリが必要ですが、通常、リポジトリに小さなリビジョンのチェンジセットが作成されます。つまり、Subversion サーバーのディスク容量は、IMPORT コマンドよりも影響が少なくなります。
一方、IMPORTは、新しいファイルを与えて「前のファイルは忘れて、このファイルを保存してください」と言ったかのように新しいファイルをインポートします。したがって、違いを解決するために時間やメモリが費やされることはありません。 、ただし、リポジトリ内の結果の変更セットは大きくなります。つまり、Subversion サーバーのディスク容量は、COMMIT コマンドよりも影響を受けますが、IMPORT は通常、はるかに高速に実行されます。
強制したいその他のワークフローは、Subversion の外部で実行する必要があります。これには、オペレーティング システムで使用可能な TAR コマンドと圧縮オプションが含まれます。「方法 1」を使用する場合は、Subversion に渡す前に、インポートするファイルを手動で単一の .tar ファイルに圧縮する必要があります。Subversion にそのようなことを依頼することはできません。もちろん、プロセスをある程度自動化するスクリプト ファイルを作成することもできますが、それでも Subversion の問題ではありません。
Subversion ワークフローに課す余分な作業に見合った価値があるかどうかを判断するために、これを使っていくつかの本格的なテストを行います。