私のチームがMercurialリポジトリ内のソースを使用して特定のプロジェクトに取り組んでいるため、リポジトリのサイズは明らかに大きくなっています。そのため、ネットワークを介したリポジトリのクローン作成はますます遅くなります。
古いコミットを削除したり、リポジトリのサイズを縮小して低速ネットワークでのクローン作成操作を高速化するために使用される手法はありますか？
（私たちはMercurialクライアントとしてTortoiseHgを使用していますが、それは（私が推測しているように）この問題の解決策に違いをもたらすべきではありません。）
1つのオプションは、拡張機能を使用してconvert、リポジトリーをより小さなリポジトリーのグループに分解することです。
多くのプロジェクト（フォルダー）を含むように進化したリポジトリがあるとします。そして、各プロジェクト（フォルダー）が別々のリポジトリーである方がよいと判断しました。拡張機能を使用して、
convertそれを実行し、変更セットの履歴を保持できます。
コンピューター上のリモートリポジトリの専用クローンを、クローン操作のキャッシュとして使用できます。したがって、レポ全体を毎回ネット経由で転送する必要はありませんが、まだ存在していない部分だけを転送する必要があります。
特定のリビジョンのファイルのみが必要であり、履歴を調べたり、新しいコミットを行う必要がない場合は、スナップショットのダウンロードを高速化できます。
通常のhgwebCGIスクリプトは、任意のリビジョンのzipまたはtarファイルを提供できます。アーカイブはその場で生成されます。追加するだけです
[web]
allow_archive = gz, zip, bz2
構成ファイルに追加します。次に、次のようなURLでアーカイブを見つけることができます。
http://server.com/repo/archive/rev.zip
リビジョン番号を、必要な変更セットハッシュのブランチ名に置き換えます。、、または同様のツールを使用してファイルをダウンロードしwgetますcurl。
この戦略は、単一のチェンジセットのサイズと比較して履歴が非常に大きい場合にのみ効果があります。
これは、リポジトリに頻繁に変更される大きなファイルが含まれている場合に当てはまります。ここでは、 largefiles拡張子を代わりに使用できます。これにより、チェックアウトするリビジョンに必要なファイルのみをダウンロードできます。そうすれば、大きなファイルの履歴をダウンロードすることを避け、かなりの量の帯域幅を節約できます。
リポジトリに大きなバイナリファイルがある場合、このような問題が発生することがあります。それらを更新すると、大きな差が生じ、サイズが通常よりも大幅に大きくなる傾向があります。
これが当てはまる場合は、Mercurial2.0で配布されているLarge-files拡張子を確認する価値があるかもしれません。私はそれを個人的に使用していません、そしてそれはまだいくつかのルージュなエッジを持っているように聞こえますがlfconvert、あなたのためにリポジトリを変換するコマンドが含まれている場合。次に、それを試して、クローンがより速くなるかどうかを確認できます。