每次我都取消搁置带有添加/重命名/移动/删除更改的变更集或 有此类更改的挂起更改，我必须手动合并接收大量活动的父项目文件(大部分代码库嵌套在一个项目下，因此其项目文件的版本更改非常频繁)。
这是每天多次的挫败感，似乎TFS应该能够为我做到这一点，因为更改很简单(例如，删除最新版本中已删除文件的行，并在本地版本中为新文件添加行)。我得出这个结论，因为它以这种方式智能地让代码文件自动合并版本。
那么，为什么自动合并对项目文件的行为与对代码文件的行为不同呢？
例如，开发人员 A 创建一个变更集，将文件添加到项目中，并将其搁置以供审阅。然后另一个开发人员 B 将更改签入到也添加一个文件(不相关)的项目，因此当我取消搁置开发人员 A 的更改时，我必须解决项目文件上的冲突。
此外，如果移动/重命名/添加一组文件，并且我想取消搁置只有一个影响更改，那么仅获取项目文件的服务器版本并手动重新应用单个更改(例如添加现有文件)要容易得多，而不是合并数千行中的十几个分散的更改。(上帝禁止您重命名更改并采用项目文件的服务器版本，因为您需要使用文本编辑器手动编辑它以进行重命名，否则由于重命名的文件已经存在于磁盘上，您将收到一系列错误尝试从解决方案资源管理器重命名时)。
更新：我正在升级这个，因为现在它把我们搞砸了。
使用VS2014和我们的代码库主要存在于一个巨大的数据库项目(*.sqlproj)下。
最有可能的是，不同的文件被添加到文件中的同一行上，因为在大多数情况下，项目文件是自动生成的，与常规代码不同，很难知道当有人在前端添加新文件项时，VS 会在哪一行插入新文件项。如果 2 个人同时向项目添加新项目，则很可能会得到 2 个版本的项目文件，这些新项目写在同一行，这会导致冲突。有时(例如，如果您添加引用)，每个项目不止一行，这使得合并变得更糟。 我建议每个对项目文件进行更改的开发人员都使用锁(专门)将其检查出来，因此一次将进行一次更改。此外，请确保其他开发人员在进行更改之前获取最新信息(Visual Studio 中 Visual Studio 中"工具">"选项"下有一个设置>"源代码管理"> Visual Studio Team Foundation Server)。这将使自动合并起作用。