1

リモート チーム用のバンドルを作成しようとしています。リビジョン 892 のデポのコピーがあり、現在はリビジョン 1119 です。

最初にパッチを試してみましたが、それらを適用しようとすると (通常はマージ送信で) 大量のファイルが作成され、リポジトリのサイズが 17 GB になるため、デルタ パッチを作成しようとしています。これには hg バンドルが最適であると考えました。

次の方法でバンドルを生成しました：

>hg bundle --rev 1119 --base 892 depot-892-to-1119.bundle

これにより、350MB のバンドル ファイルが作成されました。

しかし、リビジョン 892 にのみ移行するデスティネーション デポに適用すると、次のように表示されます。

E:\dest-depot>hg unbundle -u depot-892-to-1119.bundle
adding changesets
transaction abort!
rollback completed
abort: 00changelog.i@e5cc33458251: unknown parent!

これまでのところ、これは検索中に見た他のいくつかの質問と似ていますが、さらに一歩進めます。

ソース (より大きなデポ) で e5cc33458251 を調べたところ、明らかにリビジョン 892 より後のリビジョン 930 として表示されますが、これが失敗の理由であることを示しています。もちろん、宛先デポにはリビジョンがありません。それが、最初にバンドルを作成した理由です....だから、これがなぜ問題を引き起こしているのかよくわかりません。

現在、デポには多数のブランチがあり、リビジョン 892 はデフォルトではなく「パッチ 2.7」ブランチに反映されています。これが問題を引き起こすかどうかはわかりません。最終的に、そのパッチ ブランチは rev 999 でデフォルトにマージされました。

930 は、実際にはコードに対する非常に小さくて些細な変更であり、「パッチ 2.7」ブランチにも含まれていました。リビジョン グラフには実際には 2 つの Patch 2.7 行があり、それらは 932 でマージされました。

私はここで問題を見ていません。どの種類のバンドルを生成する必要があるかについてのアイデアはありますか? それとも、別の道を行くべきですか？

4

1 に答える 1

3

これを本質的に正しく行っているように聞こえるので、考えられるいくつかの落とし穴を確認しましょう。

リビジョン番号がクローン間で移植できないことを知っていますか? 「彼らの」892があなたのものと異なる可能性は十分にあります。そのため、nodeid で最新のリビジョンを調べ、それを base のパラメーターとして使用する必要があります。

hg serve彼らがリモートで hg の内部プロトコルを使用して実際にデータを転送するのは現実的ではないかもしれませんが、しばらくの間彼らを立ち上がらせることができれば、次のことができます。

hg bundle ../depot-to-them.bundle http://THEIR_IP:8000

そうすれば、ノード ID を送信することなく、必要なものをすべて取得するための正確なバンドルが得られます。

言及する価値があるかもしれない他の唯一の情報はさておき、使用--rev X --base Yすることで、「Yとその祖先しかない場合、Xのすべての祖先を送信したい」と言っているということです。 X にまだマージされていないブランチは、ローカルのリビジョン番号が X と Y の間にあるとしても、それを送信するつもりはありません。それはありませんが、バンドルが適用されるのを防ぎます。トラブルの考えられる原因ではなく、理解してください。

于 2013-10-07T23:30:27.773 に答える