はじめに
この記事では、水銀を扱う際のいくつかの問題（および有用な機能）について説明し、それらの解決策を提案します。
1つのフレームワーク内の複数のプロジェクト
一度に複数のプロジェクトで何らかのフレームワークを使用するとします。 これを行うために、原則として、ベースリポジトリのクローンを作成し、プロジェクト、テスト、コミット、プッシュにのみ関連するファイルの変更を開始します。すべてが通常どおりです。
突然...フレームワーク自体にバグがあるか、強度が足りない場合、機能を追加する必要がありますが、同時に現在のプロジェクトでテストします。
同時に、これらの変更は遅かれ早かれフレームワークリポジトリに反映されることを理解しています。
どうする？
最も明らかな解決策は、パッチを使用することです。 彼らは、フレームワークに関連するファイルのみを作成、チェック、選択し、パッチを作成し、プロジェクトリポジトリにパッチを適用し、必要に応じてコミットおよび開始し、必要に応じて他のプロジェクトで更新しました。
そして、あなたがこれをいつもする必要があるならば？
ここで、同じフレームワークに基づいていくつかの同様のプロジェクトに同時に取り組んでいる、または独自のフレームワークを書いている状況を想像してください。 開発用の別のリポジトリを作成し、すべてのプロジェクトの一般化された部分を開発およびテストします。 例：
ローカル開発リポジトリ ：
- コア-フレームワークファイル
- shared-プロジェクトの共有ファイル
- カスタム-テストに必要なファイル
また、一般化されたパーツ（またはフレームワーク）のリポジトリリポジトリもあります 。
- コア-フレームワークファイル
- shared-プロジェクトの共有ファイル
このリポジトリのカスタムフォルダーは自然に失われます。そうでない場合、変更すると、それらは個々のプロジェクトのリポジトリに分類され、受け入れられません。
変更は次のように配布されます。
開発リポジトリ → リポジトリリポジトリ →プロジェクトリポジトリ→（パッチ） 開発リポジトリ
最小限の神経でこれを整理する方法は？
まず、mercurialとのシンボリックリンクは機能しません。作業コピー間のファイルの分離に関連するすべてのオプションを破棄することをお勧めします。 （ハードリンクはディレクトリで実行できれば機能します）
合計で、「カスタム」フォルダーに点火する必要があります。 リポジトリのメリットとして、「無視」する主な方法が2つあります。
- リポジトリのルートで.hgignoreファイルを使用する
- .hg / hgrcを使用して無視
.hgignoreはリポジトリに配置され、個々のプロジェクトを開発するときに生活を台無しにするため、最初の方法は私たちには適していません。
しかし、2番目の方法は必要なものです。
1. .hgignoreに似たファイルを作成し、便利な場所（たとえば、.hgフォルダー内またはリポジトリー外）に配置します。
2. .hg / hgrcファイルの[ui]セクションで、オプションを作成します。
ignore.whatever = <無視するルールを持つファイルへの絶対パス>
（ところで、異なる「何でも」のようなオプションは任意の数になります）
おわりに
もちろん、記事のテキストを大幅に減らし、「無視する2番目の方法」に言及することだけに限定することもできましたが、この記事は、そのようなプロジェクトの開発についてのより深刻な議論のための紹介にすぎません。
原則として、説明されたモデルは現場で使用できますが、重大な欠点もあります。これを次回に取り除こうとすると同時に、水銀用のプラグインを作成することも学びます。