TF203015アイテム$ / path / fileには互換性のない保留中の変更があります。棚上げを解除しようとしている間
Team Server 2010に対してVisual Studio 2010 Proを使用しており、リポジトリからソリューションとして（見かけ上）プロジェクトを開いていましたが、「Webサイト」として開く必要がありました。コンパイル中にこれを見つけたので、新しい変更を棚上げしてローカルディスクからプロジェクトを削除し、ソース（今回はWebサイトとして）からプロジェクトを再度開いたところ、ファイルの棚上げを解除できませんでした。
これを回避する方法はありますか？私は何かを爆破しましたか？サーバーでメンテナンスを行う必要がありますか？
SO＃2332685 に関するこの質問ですが、彼が話しているキャッシュファイルがわかりません（XP =：\）編集： 質問を投稿した後、このリンクを見つけました。調査が遅れて申し訳ありませんが、まだ私の問題は解決しませんでした
もちろん、TF203015のエラーコードはどこにも見つからないので、解決策もありません（タイトルに数字を含めたのですね）。
編集：これらのファイルが最初にチェックインされたことはおそらくないでしょう。それは問題ですか？未チェックのアイテムを棚上げできますか？それは私が間違ったことですか？
編集：WHAP-見つけた!!! 「元に戻す」を使用 チェックインとして保留中の変更に表示されるために存在しないアイテムに対して。
変更を保留していても、ワークスペースをリロードしようとしてファイルを削除していました。 VS2010は、これらのファイルの保存がまだ保留されていると判断しました。私はそれを必要としなかったので、保留中の変更の変更を「元に戻す」ことを考え出さなければなりませんでした。
それから私は棚を開けることができました。
同時に2つのop（unshelve、commit-for-add）が実行されると考え、1つのop（unshelve）しかないと思った。
これはOPの質問から少し離れています
あるブランチから別のブランチに複数のチェンジセットを注意してバッチマージしようとすると、TF203015を取得できます。
MAINトランクとDEVブランチがある状況を考えてください。 DEVをMAINから分岐し、DEVの機能に熱心に取り組みました。進行中にDEVに戻って作業をチェックします。ここで、1〜2週間早送りします。これで機能が完成したので、MAINに再びマージします。
ここで、開発者の1人がこのエラーを見つけました。
彼は1つのソリューションに数週間取り組んでおり、変更セットを定期的にDEVにチェックインしていたため、連続していない一連の変更セットをMAINにマージしたいと考えていました。そこで、彼はマージオプションを選択し、最初の変更セットを選択します。問題なくマージし、すぐに次のチェンジセットをマージしました。 bang TF203015、および出力ウィンドウでの非常に役に立たないテスト。互換性のない保留中の変更。
少しいじってから、ここで何が起こっているのかがわかりました。最初のマージにより、開発者ソリューションのMAINに保留中の変更が作成されました。次のマージの試みは同じソリューションへの変更でもあり、TFSが同じファイルへの保留中の変更の2番目のセットを「キューに入れる」必要があります。これはできません。
したがって、このシナリオではTF203015は次を意味します。 「宛先ブランチには、このチェンジセットで変更されたいくつかのファイルに対する保留中の変更が既にあります。このマージ操作を実行する前に、宛先ブランチの変更を解決してコミットしてください。」
ソリューション;各マージ操作の後、開発者はMAINのワークスペースをテストし、マージによる保留中の変更をコミットしてから、DEVに戻って繰り返します。
実際には賢明でシンプルですが、非常に鈍いエラーメッセージによってマスクされています。
コマンドtfpt unshelveを含むTeam Foundation Server Power Tools 2011年3月（ http://msdn.Microsoft.com/en-us/vstudio/bb980963.aspx ）を使用できます。
Power Toolsをインストールしたら、Visual Studioコマンドプロンプトを開き、目的のプロジェクトを含むディレクトリに移動して、tfpt unshelveコマンドを実行します。競合を解決できるように、シェルブが解除され、マージダイアログが表示されます。
私はこのブログ投稿をこの解決策を見つける助けにしたと信じています： http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incompatible-change-while-unshelving- a-shelve-set
私は同じ問題のように見えましたが、変更を棚上げした後にブランチを作成し、それらの変更を新しいブランチに棚上げしたかったのです。
TFSは、シェルフが作成されたパスとは異なるパスにアンシェルフできません。
解決策：元のブランチに戻り、元のブランチからの変更を新しいブランチにマージしてチェックインするために、比較を超えて使用しました。
また、「テスト」でフォルダーを作成し、開発からテストにマージする場合、新しく作成されたフォルダー構造がTFSにチェックインされていない可能性があります-このエラーメッセージも表示されます。
したがって、このメッセージエラーは、SHELVESETSとは何の関係もなく、Googleから来てこのページを見つける他のユーザーにも発生します。
これはjcolebrandの答えと同じかもしれませんが、フレージングが少し難解であることがわかりました。繰り返しますが、心からおaびします。
私のシナリオでは、複数のチェンジセットをロールバックしようとしてincompatible pending changeメッセージが表示され、同じファイルがこれらのチェンジセットの複数の影響を受けました。
私の場合、すべての変更がロールバックされるまでコミットしたくありませんでした。各チェンジセットをロールバックした後にコミットできれば、エラーは発生しなかったと思います。
私のために働いた方法は次のとおりでした：
- 一度に1つのチェンジセットをロールバックすることを選択しました。 コマンドライン を使用すると、すべての競合が一覧表示されるため、実際にはより有益な方法であることがわかりましたが、VS UIロールバックでは最初の一覧のみが表示されると思います。
- チェンジセットをロールバックするときに、
incompatible pending changeがあった場合、影響を受けたファイルに対するワークスペースの保留中の変更を元に戻す必要がありました。 - すべての変更セットがロールバックされたら、
incompatible pending changeが発生したファイルを手動で元に戻す必要がありました。ほとんどの場合、これは特定のバージョンのファイル（すべての不正なチェックインが開始される前の「最後の既知の正常な」バージョン）を取得するだけで実現できます。しかし、望ましい変更と望ましくない変更の両方があった一部のファイルについては、「最後の既知の良い」を取得し、それに適切な変更を手動で適用しました。
MAIN（target）とDEV（source）の2つのブランチがある場合、DEVをMAINにマージする必要があります。ソースからマージするすべてのファイルは、ターゲットブランチ内の同様のファイルより古くない必要があります。
たとえば、DEVブランチにtest.csというファイルが変更されており、2016年3月14日に変更されました。 MAINブランチでは、2016年3月15日にtest.csが変更されています。したがって、ターゲットはソースファイルよりも新しく、TF203015があります。
解決策：TFSエクスプローラーで競合ファイルに移動し、明示的にマージします。 TFSは競合マネージャーを開き、手動で競合をマージできます。次に、選択した変更セットをマージできます。
備考：競合が多い場合は、各競合ファイルに移動して明示的にマージする必要があります。TFSは競合マネージャーを開き、手動でマージできます。
このリンクは私の問題を解決しました：
理由は、同じワークスペースで保留中の変更であり、互換性のない変更が作成されました。そのため、保留中の変更を取り消して、棚上げを解除してください。これで問題が解決するはずです。