問題タブ [mercurial-subrepos]

免責事項: 私は解決策、回避策、または物事を行う方法についてのアドバイスを求めているわけではありません。単に Mercurial の内部構造に興味があるだけです。

私はいくつかのサブリポジトリ (Git および Mercurial) を含む mercurial リポジトリを持っています。

1. 私のリポジトリとすべてのサブリポジトリはクリーンな状態です (つまり、hg st -S何も返されません)。
2. ルートでいくつかの積極的なアクセス許可の変更を行います。chown www-data:www-data -R *

これhg st -Sで、Git サブリポジトリのすべてのファイル (Mercurial のファイルは引き続き「クリーン」と見なされます) が変更されたものとして返されます。の出力hg diff -S -gは空です。なぜこれが起こったのだろうか？

これまでに発見したこと：

1. git statusサブレポの1つで実行すると、コマンドは保留中の変更を表示せず、この特定のレポは変更済みとしてマークされなくhg stなりました
2. 権限の変更をサブレポに制限すると、このサブレポのみが変更済みとしてマークされます (つまり、「問題」は.hgディレクトリ内のファイルの状態にリンクされません) 。
3. クリーン アップデート ( hg up -C) を実行すると、問題が「解決」します
4. ディレクトリでのみ権限を変更して.gitも、サブレポはまだクリーンと見なされます
5. の出力はhg --debug up -C、変更済みとしてマークされた Git サブレポとは異なります。

「クリーン」gitサブレポ：

「変更された」git サブレポ:

ですから、私が知る限り、メタデータの権限の変更はここでの原因ではありません。私はおそらく本当に単純なものを見逃しているだけです。

参考までに、私は 1.9.3 バージョンを使用していますが、以前のバージョンで同じことを言ったかどうか覚えていません。

そして、誰かが私がこのような許可の変更をやめるよう提案する前に、私はすでにそうしており、もうこの問題に直面していません.なぜ何かが起こっているのかを理解したいだけです;）

アップデート

実行git diff-index HEADすると、次の出力が得られます。

を実行するgit diff-index -p HEADと、差分は空です。なぜgitがこれらのファイルが変更されたと見なすのか、まだわかりません。

サブリポジトリで構成された Mercurial に重大な問題があります。コミットまたは更新しようとすると、次のエラーが発生します。

私の .hgsub:

Windows XP と Mercurial 1.9.2 を使用しています。私は svn と git を PATH に追加しましたが、うまくいきました。サブリポジトリを手動で更新しようとしても問題はありません。svn up と git pull はうまく機能します。

私は、各グループがメインの mercurial リポジトリのサーバー側のクローンを持つように設定されたプロジェクトに取り組んでいます。私たちが使用してきたワークフローには、ラップトップで開発し、コミットしてサーバー側のクローン リポジトリにプッシュし、それらの変更を強力なリモート マシンにプルしてテストを実行することが含まれます。変更をグループの他のメンバーと共有する準備が整うと、メインのサーバー側のクローンがローカル リポジトリにプルされ、ローカル リポジトリがメインのクローンに対してリベースされます。その後、変更をメインのリモート クローンにプッシュすると、履歴が線形履歴として表示されます。

問題は、個人のサーバー側のクローンがリベースされていないため、ローカル リポジトリと完全に同期していないことです。適切なブランチを使用していないため、マージ + リベースと移植 / 移植は、リポジトリの同期を取り戻すために使用するものではないようです。

サーバー側のクローンは、ローカル リポジトリと同じ履歴を持っている必要があります。そうしないと、すべての変更セットをプルおよびプッシュし、存在しない競合を解決するのに時間がかかります。メインからストリッピングしてプルすることなく、サーバー側のクローンにメインおよびローカルリポジトリと同じ履歴を持たせるにはどうすればよいでしょうか? 理想的には、サーバーにログインする必要はありません。

これが Mercurial で可能かどうか興味があります。手動で指定された変更セット、またはさらに良いことに、タグに常に固定されているプロジェクトにサブリポジトリが必要です。

基本的に私が達成しようとしているのは、メイン リポジトリにコア システムを配置し、次にサブリポジトリにすべてのモジュールとコンポーネントを配置することですが、それらのサブリポジトリがチップを指すのではなく、それらのコンポーネント/モジュールのメジャー リリースのみを指すようにしたくありません。 （したがって、タグ）。

キルンを使用して、この質問への回答の指示に従おうとしています。

次のように整理できるようにしたいと思います。

• /somepath/thirdpartyキルンリポジトリ「サードパーティ」にマップされ、さまざまなコードが含まれています
• /somepath/common キルンリポジトリ「共通」にマップされ、私が書いた共有コードが含まれています

と

• /somepath/project1Kiln リポジトリ「project1」にマップ
• /somepath/project1/thirdparty上記のサードパーティのブランチにマップ
• /somepath/project1/common上記の共通のブランチにマップします

と

• /somepath/project2Kiln リポジトリ「project1」にマップ
• /somepath/project2/thirdparty上記のサードパーティの別のブランチにマップします
• /somepath/project2/common上記の共通の別のブランチにマップします

指示に従ってファイルを作成し、.hgsubKiln に追加/プッシュすると、Kiln Web ファイル ビューアで Kiln ファイルを表示できなくなりました。Kiln の「過熱」に関するあいまいなメッセージが表示されました :-) さらに、正しい場所にサブフォルダーが自動的に作成されましたが、ファイルが取り込まれませんでした (プルが失敗した可能性があります)。

Kiln を使用して、以前にこのようなことを試みた人はいますか?

共通のコードを使用して多くのアプリを開発する (そして最終的にはライブラリをオープン ソースとしてリリースする可能性がある) ため、個別のリポジトリで管理したいと考えています。ただし、一部のプロジェクトはエンド クライアント向けであるため、上記の内容を含む単一のリポジトリをクライアントに提供できるようにする必要があります。

WindowsでMercurial2.0.2を実行する：

私の.hgrcで：

そして私の.hgsubで：

プッシュを実行すると、サブリポジトリのプッシュパスは、絶対パスではなく、メインリポジトリへのパスを連結したものになります。出力は次のとおりです。

私は期待していたでしょう：

サブリポジトリパスの「絶対性または相対性」は、マップされている値ではなく、.hgsubの右側のパスによって決定されるためですか？たとえば、MYREPOS / libは相対的であるため、マップされたパスは相対的であるかどうかに関係なく、相対的として扱われますか？

私たちのプロジェクトにはいくつかのリモート サブリポジトリがあり、それらのアドレスは最近 から に移動しhttp://host/pathましたhttp://other_host/path。たとえば、Mercurial がサブレポが にあると考えている先月のリビジョンに戻るにはどうすればよいhttp://host/pathでしょうか?

私は次のようなWindowsファイル構造を持っています:

Stableメインリポジトリが含まれています。 ProjectAとSharedLibraryのサブレポですStable。.hgsubファイルには次が含まれます。

ほとんどの場合、すべてが正しく機能しているようです。メイン リポジトリはサブリポジトリを認識hg status -Sし、メイン リポジトリで次のようなことを行うことができ、サブリポジトリを再帰します。 commitも正しく動作しているようです。

(メイン リポジトリ) からclone取得しようとすると、サブリポジトリのクローンを作成しようとすると失敗し、次のメッセージが表示されます。StableProjectA

ただし、リビジョンが正しく、ProjectAサブレポに存在することを確認しました。clone問題なく各サブレポできます。

これまでのところ、私は試しました：1）各リポジトリを削除して最初からやり直します。2) TortoiseHg/Mercurial を再インストールします。3) .hgsubstate にリストされているリビジョンが正しく、各サブレポに存在することを確認します。

これを修正する方法はありますか？

編集: (メイン) レポが失敗すると、サブレポなしのクローンがターゲット ディレクトリにclone残ります。clonedに移動して を実行すると、サブレポは正常に複製されますが、同じ「不明なリビジョン」エラーで複製に失敗します。その後、再度実行すると、サブレポが正常に複製されます。その時点で、最初からクローンが正しく機能していた場合と同様に、すべてが正しくなります。StableStableStablehg update tipProjectASharedLibraryhg update tipSharedLibrary

EDIT 2: の内容.hgsubstate:

ProjectAと の変更セット ID の間にスペースはありませんがSharedLibrary、これが Mercurial のやり方だと思います。の両方の変更セット.hgsubstateは、それぞれのサブレポに存在します。

編集 3: サブレポhg log --debug -r tipから。ProjectA正しい変更セットが存在することを示す

このレポ構造を取ります：

SharedLibraryは同じフォルダー（これはWindows）を指し、各メインリポジトリの下にある個別のコピー/クローンではありません。

各メインリポジトリに0と1（ヒント）の2つのチェンジセットがあると仮定します。1（ヒント）リビジョンの両方のメインリポジトリから開始します。

次の手順を実行します。

1. クライアントリポジトリで、チェンジセット0に更新します。これにより、ProjectBとSharedLibraryが以前の一致するリビジョンに更新されます。

2. ProjectAはSharedLibraryと同期していません。ステップ1は、SharedLibraryをProjectAに必要なリビジョンよりも古いリビジョンに更新しました。これはまだ1（ヒント）です。

3. サーバーリポジトリでは、SharedLibraryをProjectAの正しいリビジョンに更新する必要があるため、サーバーメインリポジトリでhgupdatetipを実行します。これにより、SharedLibraryが正しいリビジョンに更新されません。これにより、SharedLibraryはステップ1と同じリビジョンのままになります。

4. クライアントリポジトリに戻り、hgupdatetipを実行します。SharedLibraryは、ProjectAとProjectBの両方で正しいリビジョンになりました。

サーバーリポジトリでの更新は、SharedLibraryが正しいリビジョンであるかどうかを確認していないようです。この動作は予想されますか、それともこれを行うためのより良い方法がありますか？