リポジトリのサイズに問題があります。ある時点で、プロジェクト グループがビルドを svn に保持することを決定したため、リポジトリが制御不能になりました。各バイナリは約 30 MB であり、リポジトリの毎日のバックアップには 4 ～ 5 GB が必要です。数百人がチェックインした後。レポのバックアップを取り、それをネットワーク上の場所にコピーして毎日バックアップするのはかなり難しくなっています。
すべてのビルドのバックアップを保持するためのベスト プラクティスは何ですか?
ビルドを svn に置くのではなく、圧縮してどこかにコピーする svn コミット トリガーを作成できますか?
レポのサイズを縮小するにはどうすればよいですか?
svn コマンドで古いバイナリを削除できますか?
すべてのビルドのバックアップを保持するためのベスト プラクティスは何ですか?
それをしません。SVN (および他のすべて/ほとんどのバージョン管理システム (VCS)) は、差分を使用/保存することにより、テキスト ドキュメント (ソース コード) を効率的に保存するように設計されています。これはバイナリでは機能しません。
ビルドを svn に置くのではなく、圧縮してどこかにコピーする svn コミット トリガーを作成できますか?
おそらくですが、リポジトリのチェックアウトがある各コンピューターで（おそらく）実行する必要があるのは主要なハックです。リポジトリをチェックアウトするときにこれらの zip を再度取得する場合は、さらに面倒です。
レポのサイズを縮小するにはどうすればよいですか?
古いバイナリを svn コマンドで削除できますか?
SVN (および他のほとんどの VCS) に何かをコミットすると、それは残り、履歴を変更することはできません。つまり、すべての変更をコピーできる新しいリポジトリを作成できます（コミットメッセージを保持するためのツールがいくつかあります）。おそらく、すべてを (ビルドなしで) 再コミットして、それ以降そのリポジトリを使用することが可能です。(問題を防ぐために、すべてのプロジェクト パートナーが新しいリポジトリをチェックアウトしていることを確認してください)
お気づきのように、すべての派生ファイル (ビルド) を VCS に保存することは「良くないこと」です。再現性のために、代わりに、使用したツールのバージョン番号などのビルド情報を保存できます。そのため、必要に応じて特定のビルドを再構築することが常に可能です。
最新のビルドのみを含む共有の場所を使用して、すべてのプロジェクト パートナーがこの最新のビルドを表示/試行できるようにします。
ただし、もう VCS に保存しないでください。
すべてのビルドのバックアップを保持するためのベスト プラクティスは何ですか?
すべてのタスクに適切なツールを使用してください。ソース管理はビルドのアーティファクトを管理できますが、不十分です。このジョブにアーティファクト マネージャーを使用する
ビルドを svn に置くのではなく、圧縮してどこかにコピーする svn コミット トリガーを作成できますか?
はい、理論的にはフックで何でもできます (ビルド、アーカイブ、デプロイ) が、(ここでも) 特別なツールを使用すると、エンド ユーザーにとってより簡単かつスムーズに実行できます (「Jenkins」、「Maven」を読んでください)。
レポのサイズを縮小するにはどうすればよいですか?
ダンプを作成し、ダンプ内の不要なリビジョンを削除し、洗練されたダンプを復元します
svn コマンドで古いバイナリを削除できますか?
svnadmin-|dumpfilter-hacking dump のみで、クライアント側のツールでは実行できません