誰も明確に書き込もうとしている人はいないという事実を垣間見たようです。これがなければ、どういうわけか私には理解できませんでした。 私は、VSSでのかなりの経験と、SVNの面倒を見る経験があります。 そして今、私はすべてのGITを見ています。
Mercurial.selenic.com/wiki/UnderstandingMercurialページでは、SVNのようなシステムで慣れているように、HGリポジトリにいくつかの関連プロジェクトを保持することを考えている場合、HGはそのために設計されていないため、よく考えてください。 これは、作業フォルダー全体で常に機能するためです。
これは、私が言いたいことの結果の良い例です。これらの新しい分散システムでは、ディレクトリツリーと作業フォルダ内のファイルの概念は、 バージョンツリー と直交して います 。 これは、これらのシステムと以前のシステムとの2番目の（ ローカルリポジトリを使用した後の）重要な違いです。
SVNおよびVSSでは、同じ作業フォルダーの異なるバージョンをリポジトリの他のフォルダーの隣接フォルダーとして設計することが提案されたため、リポジトリフォルダーツリーには1つの作業フォルダーではなく、リポジトリの個別に特別に作成されたルートフォルダーの異なるサブフォルダーにあるそれらのセット全体が含まれていましたブランチやトランクなどの多数のサービスサブフォルダー。 これにより、システムはユーザーにリポジトリの1つのサブフォルダー、次に別のサブフォルダーで作業し、履歴を保存しながら相互にコピーし、隣接するフォルダーを相互にマージするなどの機会を与える必要に至りました。 そして、このスキルの結果として、これらのシステムは、同じリポジトリの他のサブフォルダーに、他の関連するプロジェクトの作業フォルダーのバージョンを保存することを可能にしました。 そして、それに応じて、さまざまな人々に対するさまざまなフォルダへの権利は異なったものを与えます。 まったく見えない人もいれば、編集しない人もいます。
しかし、GITとHGはバージョンツリーとフォルダーツリーの概念を分離していたため、最初はサブフォルダーでの作業をサポートする必要がなく、常にリポジトリ全体で作業フォルダーで作業し、そのバリアントはその履歴内でのみ分岐します。
通常、ディスク上のそのようなリポジトリからフォルダーの2つのバージョンを同時に表示できます-あるバージョンの状態で作業フォルダーをコピーできるのは、どこかで作業フォルダーを切り替えて別のバージョンを表示するだけです（=ローカルリポジトリから別のバージョンを選択します）。 ただし、これはgitとの関連性が高いためです。hgでは、コメントとrg03.wordpress.com/2009/04/07/mercurial-vs-gitで判断すると、多くの場合、リポジトリ全体が複製されます（？）そして次のフォルダに。 リポジトリーには独自の作業フォルダーがあります。 一種の「ステロイドの作業フォルダー」。 （メイン作業フォルダーの特定のパスのライブラリーソースを検索するように構成された開発環境は、ライブラリーを含む作業フォルダーの移動にどのように反応するのでしょうか？または、Unixの方法では発生しませんか？）
また、アクセス権-ファイルシステムを使用するか、このリポジトリの所有者に適さない別のリポジトリから送信された編集の一部を拒否する手順ハックを作成することにより、リポジトリ全体に対してのみ。 今、彼らは追いつく方法を考えています-例えば、HGはサブレポを作ります...