因此，在开发人员的典型工作流程中，它是这样的：
您将工作区同步到某个变更集，做一些工作，搁置您所做的更改。
我的问题是，在内部，当您创建搁置集时，TFS是否会跟踪更改所基于的变更集？如果是这样，有没有办法查看这个？
我的基本理解是，是的，这个变更集信息必须以某种方式记录，因为搁置集在内部存储为delta，而不是文件的完整副本，并且没有记录delta所基于的变更集，delta基本上是无用的。
这可能是您团队的典型工作流程，但我会说这不是一般的典型工作流程。
Shelvesets用于短期暂停正在进行的工作，这些工作尚未准备好提交给dev分支，通常是在需要立即切换上下文（例如，故障排除或修复错误）的特殊情况下。
在内部，TFS实际上将大多数文件存储为reverse deltas。为什么？可能是因为最常访问的文件状态是当前版本，并且必须通过向原始文件播放一系列更改来“构建”当前版本将会更加昂贵。基本上，当你去查看一个旧版本的文件时，它会获取文件的当前版本并“剥离”干预的更改，直到它回到旧版本。
您的具体问题实际上是直接解决的：
Shelvesets也使用相同的机制来存储其内容。但是，对于搁置集，不会发生deltaedication。每个shelveset都会获取其文件的新副本。 （合并的情况除外）。签入搁置集时，会发生浅拷贝，并且文件的已提交版本使用与所引用文件的搁置集副本相同的内容。 Deltafication将在以前版本的文件上启动。
因此，长话短说，搁置集不是基于变更集。
我同意Daniel的回答，即Shelveset的文件是新文件的副本。但是，我不确定它何时被合并但目前在VS2017中实际存储了Changeset。查看Shelveset详细信息时，如果将光标悬停在文件中显示的详细信息中的文件是“版本”，则它基于。
我不知道这对于典型的用户有多大用处，因为我发现Shelvesets的一个最好的功能是模块化和与版本控制的分离，但是从来没有伤害到这个上下文。
干杯!