gitに移行するときに大きなsvn履歴についてどうすればよいですか？
編集は、次のようないくつかの類似した質問とは異なり、GitリポジトリへのマルチGBのSVNリポジトリの移動 や /programming/540535/managing-large-binary-files-with-gitを 私のシナリオでは、といういくつかのサブプロジェクトを含みません簡単にgitサブモジュールに変換することも、git-annexに適した非常に大きなバイナリファイルに変換することもできます。バイナリが、グラフィックなどのコンパイル時のアセットであるかのように、同じリビジョンのメインソースコードに密結合したテストスイートである単一のリポジトリです。 私は、svnから古い中/大サイズ（50ユーザー、60kリビジョン、80Gb履歴、2Gb作業コピー）のコードリポジトリの切り替えを調査しています。ユーザーの数が増えると、トランクに大量のチャーンが発生し、多くの場合、機能が複数のコミットに分散し、コードのレビューが困難になります。また、分岐せずに不良コードを「ゲート」する方法はありません。レビューはトランクにコミットされた後にのみ実行できます。私は代替案を調査しています。gitに移行できることを望んでいましたが、いくつか問題があります。 gitに関する限り、現在のリポジトリの問題はサイズです。そこには多くの古いクラフがあり、gitに変換するときに--filter-branchでクリーニングすると、サイズが1桁、つまり5〜10 GBに削減されます。これはまだ大きすぎます。リポジトリサイズが大きい最大の理由は、テストへの入力であるバイナリドキュメントが多数あることです。これらのファイルは.5mbと30mbの間で異なり、数百があります。また、非常に多くの変更があります。私はサブモジュールやgit-annexなどを見てきましたが、完全な履歴が必要な多くのファイルの別館があるのと同様に、サブモジュールでのテストが間違っていると感じています。 したがって、gitの分散された性質は、実際にGitを採用することを妨げるものです。分散についてはあまり気にしません。安価な分岐機能と強力なマージ機能が欲しいだけです。私がgitユーザーの99.9％がそうするように、私たちは祝福された裸の中央リポジトリを使用します。 gitを使用するときに各ユーザーが完全なローカル履歴を保持する必要がある理由を理解できませんか？ワークフローが分散化されていない場合、そのデータはユーザーのディスク上で何をしているのでしょうか？gitの最近のバージョンでは、最近の履歴のみを持つ浅いクローンを使用できることを知っています。私の質問は、これをチーム全体の標準操作モードとして実行することは可能ですか？gitを常に浅く設定して、完全な履歴のみを中央に持つことができますが、デフォルトではユーザーは履歴の1000回転しか持つことができませんか？もちろん、そのオプションは1000回転をgitに変換し、考古学のためにsvnリポジトリを保持することです。ただし、このシナリオでは、テストドキュメントの次の数千の改訂後に同じ問題が再び発生します。 あなたがいることを多くのバイナリファイルを含む大規模なレポでのgitを使用するための優れたベストプラクティスは何であるかの履歴をしたいの？ほとんどのベストプラクティスとチュートリアルは、このケースを回避するようです。少数の巨大なバイナリの問題を解決するか、バイナリを完全に削除することを提案します。 浅いクローニングは通常の操作モードとして使用できますか、それとも「ハック」ですか？ メインソースリビジョンとサブモジュールリビジョンの間に強い依存関係があるコードにサブモジュールを使用できますか（コンパイル時のバイナリ依存関係、ユニットテストスイートなど）。 gitリポジトリ（オンプレミス）の「大きすぎる」とはどのくらいですか？4GBまで下げることができたら、切り替えを避けるべきですか？2GB？