したがって、開発者の典型的なワークフローでは、次のようになります。
ワークスペースをいくつかの変更セットに同期し、いくつかの作業を行い、行った変更を棚上げします。
私の質問は、内部的には、シェルブセットを作成するときに、TFS は変更がどの変更セットに基づいているかを追跡しますか? もしそうなら、これを調べる方法はありますか？
私の初歩的な理解では、はい、このチェンジセット情報は何らかの方法で記録する必要があるということです。なぜなら、ファイルの完全なコピーとは対照的に、シェルフセットはデルタとして内部に保存され、デルタが基づいているチェンジセットの記録がなければ、デルタは基本的に役に立たないからです。
これはあなたのチームの典型的なワークフローかもしれませんが、一般的には典型的なワークフローではないと思います.
シェルフセットは、開発ブランチにコミットする準備が整っていない進行中の作業を短期間中断することを目的としています。通常、コンテキストをすぐに切り替える必要がある例外的な事態が発生した場合 (トラブルシューティングやバグの修正など) に使用されます。
内部的には、TFS は実際にはほとんどのファイルを逆デルタとして格納します。なんで？おそらく、最も頻繁にアクセスされるファイルの状態が現在のバージョンであり、元のファイルへの一連の変更を再生して現在のバージョンを「ビルド」する必要があるため、はるかにコストがかかるためです。基本的に、ファイルの古いバージョンを見に行くと、ファイルの現在のバージョンが取得され、古いバージョンに戻るまで、介在する変更が「剥がされ」ます。
あなたの特定の質問は実際に直接対処されています：
シェルフセットもコンテンツを格納するために同じメカニズムを使用します。ただし、シェルフセットでは、デルタ化は発生しません。各シェルブセットは、そのファイルの新しいコピーを取得します。（合併の場合を除く）。シェルブセットがチェックインされると、シャロー コピーが発生し、ファイルのコミットされたバージョンは、参照されたファイルのシェルブセット コピーと同じ内容を使用します。差分化は、ファイルの以前のバージョンで開始されます。
要するに、シェルフセットは変更セットに基づいていません。