この質問も参照してください。
何をしているのかわからないまま、largefiles拡張子を有効にし、ファイルをコミットしてキルンにプッシュしました。今、私は自分のやり方の誤りを知っており、この変更を永久に元に戻す必要があります。
私はこの件についてSOからのガイダンスに従いました。ラージファイルをローカルで削除することはできますが、これはキルンのリモートリポジトリには影響しません。KilnサーバーのKilnRepositoriesでリポジトリを開き、largefilesフォルダーを削除しようとしましたが（requiresファイルから'largefiles'を削除しました）、数回プッシュ/プルした後、フォルダーとrequireの行が戻ってきました。
これを永続的にする方法はありますか？（読み取り専用に設定する必要もありません）。
注：これは、少なくとも（Windowsの場合）TortoiseHg 2.4（Mercurial 2.2.1）-> 2.7.1（Mercurial 2.5.2）に当てはまります。将来のバージョンや古いバージョンについては話しません。
利用可能なさまざまなMercurial拡張機能を調べた結果、largefiles拡張機能を使用してファイルがコミットされると、リポジトリを「元に戻す」ことは通常不可能であると結論付けました。
まず、リポジトリでラージファイルを使用したくない理由の2つの理由：1と2。
ファイルがラージファイルとしてコミットされたら、それを削除するには、「。hglf」パスへのすべての参照をリポジトリから削除する必要があります。コミットの内容は「.hglf」フォルダーを含むファイルのパスを参照するため、バックアウトは十分ではありません。Mercurialがこれを確認すると、「largefiles」が/.hg/requiresファイルに書き戻され、リポジトリがもう一度largefileロックされます。同様にhgで忘れて削除します。
オプション1：リポジトリが分離されている場合（ローカルおよびリモートのすべての場所でリポジトリをエンドツーエンドで制御でき、他の誰もこのリポジトリから分岐していない場合）、mq拡張機能を使用してチェンジセットを取り除きます。これはおそらく、時間内に間違いを見つけた場合にのみ実行可能なオプションです。
オプション2：問題のあるチェンジセット（ラージファイルコミット）がドラフトである（またはドラフトに強制的に戻すことができる）コミットフェーズに存在する場合、コミットをmqにインポートし、hgqpopを使用してチェンジセットを適用解除できる場合があります。これは、抽出された変更セットから転送されたコミット履歴を保持するため、ストリッピングよりも優れています。実生活では、これは多くの場合不可能です。これは、すでにマージを実行し、パブリックフェーズブランチからプッシュ/プルされている可能性があるためです。ただし、すぐに捕まえられた場合、mqはリポジトリを救済する方法を提供できます。
オプション3：問題のあるチェンジセットが1つの場所でのみ参照され（元のコミット）、誰もチェンジセットをバックアウト/削除/忘れようとしない場合（したがって複数の参照を作成する場合）、hgrebaseを使用できる可能性があります。オフェンスの親チェンジセットを使用して、オフェンス後の最初の子チェンジセットをフォールドします。そうすることで、攻撃的なチェンジセットは新しいヘッドになり、mqストリップで取り除くことができます。これは、mqへのインポートの試行が失敗した場合に機能します。
オプション4：上記のいずれも機能しない場合は、移植または移植を使用して、問題のないすべてのチェンジセットをパッチとしてエクスポートし（正しい順序でエクスポートするように注意してください）、問題の前に最初の正常なチェンジセットに更新します。 、mqは、すべてのフォワードチェンジセットのリポジトリを削除してから、エクスポートしたパッチを順番に再適用します。
オプション5:(私が最終的に行ったこと）。リポジトリのクローンを作成して、clone_to_keep、clone_to_destroyの2つのコピーを作成します。clone_to_keepで、オフェンスの前に最初の正常なチェンジセットに更新します。Mqはすべての前方チェンジセットを取り除きます。複数のヘッドが残っている場合は、下にマージします。clone_to_destroyで、ヒントを更新します。Windowsエクスプローラーで、.hgフォルダーと.hglfフォルダーを除く/clone_to_destroy内のすべてを/clone_to_keepフォルダーにコピーします。Tortoise内で、clone_to_keepのすべての変更を単一のチェンジセットとしてコミットします。clone_to_destroyの1つのリモートインスタンスを履歴目的で読み取り専用状態に保持し、他のすべてを破棄します。
オプション6：核オプション。他のすべてが失敗し、リポジトリと外部システム（バグ追跡、CIなど）の統合を気にしない場合は、前述のSO投稿に従って、 hgconvert拡張機能を使用できます。これにより、感染したリポジトリの新しいコピーが作成され、問題のあるチェンジセットへのすべての参照が削除されます。ただし、これは、リポジトリ全体の各チェンジセットを繰り返し、それを新しいチェンジセットとして新しいリポジトリにコミットすることによって行われます。これにより、既存のブランチリポジトリと互換性のないリポジトリが作成されます。チェンジセットIDはいずれも整列しません。ブランチリポジトリがない場合を除いて、このオプションはおそらく機能しません。
いずれの場合も、修正を行い、個別のリポジトリインスタンスごとに手動で再適用する必要があります（リポジトリフォルダをコピーし、クローンを作成します）。
結局、ラージファイルを有効にすることは非常に費用のかかる間違いであることがわかります。修正には時間がかかり、最終的には破壊的です。大きなファイルをリポジトリに含めることを許可することはお勧めしません。