問題タブ [unshelve]

私のチームの一部の開発者が、ブランチ A で行った変更を棚上げしたとします。そして、私はブランチ B で作業しています。彼の変更をブランチ B に棚上げ解除できますか? (GUI またはコマンドプロンプトで)

Here's the part I get: When you shelve in TFS, it makes a server copy of the changes so they are not lost, but does not check them into the source code trunk/branch you are working on.

Question: Under what circumstances would you use the "unshelve" feature? Does it mean it will remove the shelveset from the TFS server? Can you do a get from a shelveset? Or is it really just a diff description between the shelveset and the "real" source code?

私たちのチームは Mercurial を使い始めたばかりです。私たちが最初に遊び始めたものの 1 つは、 ですhg shelve。ローカルでは、変更を棚上げすることに問題はありません。私が知る限り、それはすべて完璧に機能します。ただし、保留を解除しようとするとrestoring backup filesメッセージが表示されますが、実行するhg diffと変更がなく、コードに変更がありません。そうすればhg unshelve -i、差分を見ることができますが、棚上げを解除しようとしても効果がないようです。

テストコメントを追加するなど、競合に関して問題にならない非常に単純な変更を加えてテストしようとしています。私は試してみたことに注意する必要がhg unshelve -fありますunshelve completedが、その後、私の変更は復元されません。

私が間違っていることは何ですか？

問題がある場合: Mercurial Distributed SCM (バージョン 1.5.1+20100405)

Team Server 2010 に対して Visual Studio 2010 Pro を使用しており、プロジェクトを (明らかに) リポジトリからのソリューションとして開いていましたが、「Web サイト」として開く必要がありました。コンパイル中にこれを見つけたので、新しい変更を棚上げし、プロジェクトをローカル ディスクから削除してから、プロジェクトをソースから (今回は Web サイトとして) 再度開いたところ、ファイルの棚上げを解除できなくなりました。

これを回避する方法はありますか? 私は何かを爆破しましたか？サーバーでメンテナンスを行う必要がありますか?

SO #2332685 でこの質問を見つけましたが、彼が話しているキャッシュ ファイルはわかりません (私は XP を使用しています :\ ) 編集:質問を投稿した後にこのリンクを見つけました。問題を解決する

もちろん、TF203015 のエラー コードがどこにも見つからないので、解決策もありません (そのため、タイトルに番号を含めましたよね?)

編集:これらのファイルは最初からチェックインされていないことに言及する必要があります。それは問題ですか？未チェックの商品を棚上げできますか？それは私が間違ったことですか？

編集: WHAP - 見つけました!!! 保留中の変更にチェックインとして表示されるため、存在しないアイテムに対して「元に戻す」を使用します。

デポに保留されているファイルを保留解除するときに、ワークスペース内の既存の開いている変更済みファイルに変更をマージするようにPerforceに指示するにはどうすればよいですか? Perforceがユーザーに提供しているように見える唯一のオプションは、ワークスペース内の既存のファイルを上書きまたは元に戻すことですが、これでは、たとえば、複数の変更リストから同じファイルへの変更を保留解除して統合することはできません. この制限を回避する方法はありますか?

CL1000のPERFORCEシェルフがあります。不明なCLXで他の誰かによってシェルフされました。

私はCL2000にいます。Xが何であれ同期して1000のシェルフを解除したいので、コードはシェルフされたときとまったく同じになります。どうすればよいですか？

あるブランチから別のブランチにシェルブセットを移行したいと考えています。これが私のコマンドです：

tfpt unshelve MigrateShelf /migrate /source:"$/Code/OldBranch/Source" /target:"$/Code/NewBranch/Source"

実行すると、ウィンドウがポップアップしますが、まだ OldBranch に取り出されています。

私はこの質問を見ます

TFS の tfpt migrate は何もしません

彼は同じ質問をしているようですが、彼は回答を受け入れた後、問題が解決しないと不平を言いましたか?

数日前に追加されたシェルフセットを棚から外したかっただけです。一方、他の誰かが、シェルブセットに含まれるファイルの新しいバージョンのチェックインに成功しました。最新バージョンとシェルブセットの間でファイルに競合が存在するため (別のベースチェンジセットがあるため)、コードベースをシェルブセットで使用されるこの特定のバージョンに戻したいと考えています。

どのベース バージョンのシェルフセットが使用されているかを判断するにはどうすればよいですか? 残念ながら、「詳細」-シェルフセットの情報には、これに関する情報はありません。

UserAが Perforce で変更リストを作成し、それを棚上げできるようにしたいと考えています。次に、 UserBがそのチェンジリストの保留を解除してサブミットできるようにしたいと考えています。

これは簡単に聞こえますが、Perforce のシェルフ解除は期待どおりには機能しないようです。UserB が 'p4 unshelve -s 1234' を実行すると、変更 1234 から変更されたすべてのファイルが取り消されますが、変更のメタデータ (説明、ジョブ修正) は取り込まれません! これは、UserB が棚上げされた CL をまったく新しい CL にコピーして送信できることを意味します (説明と修正を手動で再作成することによって) が、古い棚上げされた CL がそのまま残ります。

ここでの論理的なことは、UserBが

1. CL の棚上げを解除する
2. 棚上げされた CL のメタデータを表示する
3. そのメタデータを新しいCLにコピーします。
4. 新しい CL を提出する
5. 古い保留 CL を削除する

これは、Perforce のドキュメントでも推奨されていることです。ちょっとした問題が 1 つあります。UserB は、別のユーザーの保留された CL を削除することはできません! UserA と p4 管理者のみが、保留中の CL を削除できます。ドキュメントがこれを正しく説明していない理由がわかりません。

以前にこの問題が発生したことはありますか? どのように解決しましたか？

編集:私の質問は非常に一般化されていることを明確にする必要があります。UserAが開発者で、UserBがビルド システム自体であるツールに取り組んでいます。開発者は CL を棚上げしてから、ビルド システムの棚上げを解除し、一連のビルドとテストでそれを検証します (これらのすべてのテストに合格した場合、CL を自動的に送信します)。ビルド システムが保留中の CL を提出した場合、すべての開発者が忘れずに CL を削除することを期待するのは、失敗する運命にあるようです!