我们的产品类似于游戏，并且在二进制支持文件（纹理、网格、电影等）中非常丰富（~40M - 100M）。 像 kai1968 一样，我希望能够同步这些资产，而不仅仅是代码，只需单击一下。
然而，严格来说，这与版本控制不同：我不想让我们的 TFS 负担这些文件的不相关历史记录。我可以在不将历史记录保存到 TFS 的情况下以某种方式上传内容吗？如果我可以选择将历史记录保留在特定点（例如标签点），而不是在每次签到时，那就更好了。
更一般地说，您如何管理二进制资产的同步？
（我知道其他工具，可能更适合此类任务，但从 TFS 分流（或完全迁移）现在不是一种选择。）
我们总是在需要时将二进制资产保存在 TFS 中，并且只处理该选择的副作用（额外存储、更长的签入，因为您无法对二进制文件进行差异等）。我不相信有一种方法可以选择性地破坏某些文件的历史记录，除了手动。如果您想定期手动执行此操作，您可以执行以下操作：
您将只有最新的副本，但这有一个副作用 - 您会破坏任何以前的构建，因为尝试检索源历史不会返回文件的这些新副本。TFS 将检查与您尝试的结帐匹配的副本，如果找不到，则不会检索这些文件的副本。如果您想构建旧版本，则需要更新构建脚本以提取最新的二进制文件以及历史代码，但即便如此，它也不是真正的历史。
第二种选择是只定期检查它们——而不是每一次微小的变化。例如，将这些文件保存在安全的地方（与每日备份的文件共享），然后仅在每周左右检查更改的二进制文件，或在每个标签之前检查，或其他 - 这样，您没有增量历史记录，但是你仍然有你的标签历史。您甚至可以考虑编写某种自动化例程来应用标签，它会首先检查该文件夹中的任何更改，然后应用标签。
请发回你最终做了什么——我很想知道！
这里有一些想法：
考虑使用单独的 VSTS 项目，这样就不会在同一个项目中混合二进制文件和代码。这使它更易于管理（例如，您可以将资产分开，并且与它们相关的任何工作项都可以通过项目过滤更容易地查询）。不利的一面是，这意味着点击 2 次即可获得最新信息。
为什么不想保留历史？源代码控制的重点是保留历史记录，以便您可以回到特定日期的特定构建。否则，您还不如在网络驱动器上使用备份程序（而您真的不想这样做！）
如果您只担心磁盘空间使用情况，那就不要。100MB 很小，而且硬盘很便宜。我的上一个游戏项目有数百 GB 的资产，我们将每次更改的历史记录保存了 3 年以上。
这些资产不会减慢任何速度。如果您签入或获取它们，它们只需要时间来处理，即使您不使用源代码控制，这两项活动也需要执行。事实上，源代码控制使事情变得更快，因为您拥有“一键完成所有”的解决方案。
源代码控制的许多其他好处对资产非常有用，并且大大超过了负面影响。