既存のプロジェクトを Mercurial にインポートしようとしています。プロジェクトは5GBを少し超えています。
hg push を実行しようとすると、バッファ領域が不足しているというエラーが常に表示されます。
最初のコミットを行う良い方法を知っている人はいますか?
既存のプロジェクトを Mercurial にインポートしようとしています。プロジェクトは5GBを少し超えています。
hg push を実行しようとすると、バッファ領域が不足しているというエラーが常に表示されます。
最初のコミットを行う良い方法を知っている人はいますか?
Mercurial の使用に縛られていない場合は、boarを使用することもできます。これは Mercurial のような DVCS ではなく、Subversion の場合とほとんど同じ方法で、データを保存し、ファイルのバージョンを「チェックアウト」する中央リポジトリがあります。
重要な部分は、大きなバイナリ ファイルを保存するという明確な目的で書かれていることです。
私はそれを使用していないので、その仕事がどれほど優れているか、またはどれほど安定しているかについてはコメントできませんが、あなたのニーズに十分に合う可能性のある代替手段です.
このような大規模なコミットを実際に Mercurial に入れる必要があると仮定すると、コミットのサイズは、数百万の小さなファイルではなく、主に少数の biiiig ファイルによるものだと思います。この場合、必要に応じてLarge Files Extensionを調べることができます。大きなファイルを追加すると、コンテンツではなくチェックサムによって追跡されるため、Mercurial 自体が追跡するものは比較的小さくなります。拡張機能がバージョンを処理します。
ただし、Alex Stuckey が言及しているように、通常、コンパイル済みのバイナリ (オブジェクト コード、結果の実行可能ファイルなど) などをコミットするべきではありません。これは、大きなコミットを行う最も可能性の高い理由です。適切な.hgignore
ファイル (通常の疑わしいファイルを削除するファイル - *.o
、*.pdb
、何でも ...) を作成することをお勧めします。これにより、将来そのようなファイルを誤って追加することを防ぐことができます。.hgignore
私は、最初のコミットとしてほぼすべてのリポジトリに入れられる標準を持っており、うまく機能しています。
Mercurial にバイナリ ファイルを保存することが推奨されない理由の簡単な説明については、 https://www.mercurial-scm.org/wiki/BinaryFiles およびhttp://kiln.stackexchange.com/questions/1074/why-is-itを参照してください。 -mercurial にバイナリ ファイルを保存するのが悪い
私たちの場合、Dropbox を使用してバイナリ ファイルを処理します。ファイルの履歴を保持し、チーム メンバー間でフォルダーを同期することができます。ファイルの履歴を保持する必要がない場合は、rsync を使用してバイナリの同期を維持できます。