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