2011-01-20 11 views
5

私は、hgsubversionを使用してSVNリポジトリからクローン化された履歴を含む中央のMercurialリポジトリを持っています。元のhgリポジトリがクローニングされて以来、私はSVNリポジトリに加えられた追加のコミットを引き出しました。これらは現在デフォルトのブランチにあります。Mercurialを使用して、どのように名前付きブランチに変更するのですか?

また、名前付きブランチもあります。私はこのブランチを(hg clone -b mybranchを使って)私のローカルシステムに複製しました。今私は既定でのみ存在する変更を取得し、それらの名前付きブランチで利用できるようにしたいと思います。私がそれを行うために見る明らかな方法は、hg update mybranchをリポジトリで行い、次にhg merge defaultをコミットすることです。これは危険なようです - 私が完了した後にデフォルトに戻って更新するのを忘れた場合、SVNからのすべての引き出しはmybranchに変更されます。

また、私はレポを複製する場合、おそらく私はmybranchを指定しているべきではないと考えられているが、全体のレポをクローニングして、ちょうどローカルmybranchに更新しました。したがって、私はデフォルトでローカルクローンに変更を引き込み、そこでマージを行うことができます。

ここで正しい答えは何ですか?共有リポジトリでそれを行い、注意するだけですか?すべてをクローンし、ブランチをローカルで管理しますか?それとも、簡単な解決策がありますか?

+1

マージはちょうど完璧と思われますが、私はあなたの問題を実際には感じません。 * hgsubversion *はSVNブランチを認識しているようですので、* SVN-trunk *の変更を* default *に、* SVN-mybranch *を* mybranch *ブランチに入れる必要があります。 * mybranch *にマージしていれば、リモート側にトランクのみの変更がある場合、* mybranch *のヒントは本当に変わりますか?プルは作業コピーのリビジョンとは独立して動作するはずです。 –

+0

私の懸念事項は、マスターリポジトリとそれに関連するリスクを直接変更することでした。もちろん、DVCSの世界では、すべてのreposは本質的に等しいので、おそらく私のクライアント/サーバVCSバイアスです。 –

答えて

6

一般にMercurialでは、私が問題を引き起こすと思われる何かを行うたびに、私はレポをクローンしてそこで試してみます。次に、これらの変更を元に戻したり、実際のリポジトリでアクションを実行したりすることができます。いずれにしても、私は失敗して損害を与えないという選択肢があります。 クローンはに投げ捨てることができます。あなたが倒れた場合、それらを守る必要はありません。

+1

それは良い点です、とにかく私が傾けていた答えです。私が欠席していたhgの特徴がないことを確認したかったのですが、私が投稿したSOの質問のほとんどにfirehoseのような応答率があることは考えられませんでした。 –

1

共有リポジトリで行い、注意してください。または、共有リポジトリ全体をクローンしてそこにマージし、ブランチのみのクローンにプッシュします。

関連する問題