我应该把二进制资产放在TFS下吗？如何操作？

Question

我们的产品类似于游戏，二进制支持文件非常丰富（约40M - 100M）- 纹理、网格、电影等等。就像kai1968一样，我希望能够通过单击同步这些资产，而不仅仅是代码。

严格来说，这与版本控制是不同的：我不想让我们的TFS负担这些文件的无关历史记录。我是否可以以某种方式上传东西到TFS而不保留历史记录？如果我可以选择在特定点（比如标签点）保留历史记录，而不是每次提交都保留历史记录，那就更好了。

更一般地说，你如何管理二进制资产的同步？

（我知道有其他工具，也许更适合这些任务，但现在离开或完全迁移TFS不是一个选项。）

- Ofek Shilon

Answer 1

我们一直将二进制文件存储在TFS中，只是应对了这种选择的副作用（额外的存储空间，因为无法在二进制文件上进行差异比较而导致的更长的检入时间等）。我认为没有办法有选择性地销毁某些文件的历史记录，除非手动操作。如果您想定期手动执行此操作，可以按照以下步骤进行：

1. 获取二进制文件的当前副本
2. 销毁（删除并包含历史记录）TFS中的二进制副本
3. 手动将文件添加回TFS

这样您就只拥有最新的副本，但是它会带来一个副作用 - 你会破坏任何以前的构建，因为尝试检索源代码历史记录时不会返回这些文件的新副本。 TFS将检查是否存在与您正在尝试签出的匹配副本，如果找不到，则不会检索这些文件的副本。 如果您想构建旧版本，则需要更新构建脚本以拉取最新的二进制文件以及历史代码，但即使如此，它也不会是真正的历史记录。

第二个选项是仅定期检入它们 - 而不是每个细微更改都检入。例如，将这些文件保存在某个安全的位置（具有每日备份的文件共享中），然后每周或每个标签之前只检入更改的二进制文件，或者采取其他方式 - 这样，您就没有增量历史记录，但您仍将拥有标签历史记录。 您甚至可以考虑编写某种自动例程来应用标签，它会首先检入该文件夹中的任何更改，然后应用标签。

请回复您最终采取的措施 - 我很想知道！

- SqlRyan

---

我担心答案可能是这样的......一个不是一键式签入/获取最新版本的解决方案会失去目的。我们将通过网络共享单独同步二进制资产。谢谢！ - Ofek Shilon

我之前给了这个答案一个+1，但仍然看不出问题在哪里。它与“一键签到/获取最新”有何不同？只需在磁盘空间不足时每隔一段时间运行销毁脚本即可。 - Richard Berg

看起来2005不支持“Destroy” - 这是在2008年添加的，我没有访问权限，所以其他人将不得不测试并填写，但我的怀疑是“Destroy”会破坏构建。如果您创建了一个标签，然后销毁了该标签中的某个文件，然后检入了另一个同名文件，然后尝试获取标签，我不确定会发生什么 - 可能TFS获取更新的文件，可能获取不包括已销毁文件的标签，也可能显示“无法获取标签”。无论如何，它都无法完全复制您标记的设置，因为该文件已经不存在了。 - SqlRyan

@Richard：根据我的经验，偶尔维护比每次维护更加繁琐。 - Ofek Shilon

@rwmnau - 如果没有破坏的文件，它将获得标签。如果这是一个问题，您需要相应地调整构建过程。@Ofek - 公平的。 - Richard Berg

那么你只需要将构建过程设置为，如果标签版本不可用，则获取下一个可用版本？我想这是可行的，但我不喜欢破坏构建的想法——如果您无法精确地重新创建标签时存在的内容，那么标记的意义在哪里呢？ - SqlRyan

Answer 2

以下是我的翻译：

以下是一些想法：

• 考虑使用一个单独的 VSTS 项目，这样你就不会把二进制文件和代码混在同一个项目中。这使得管理变得更容易（例如，你可以将资产分开，并且任何与它们相关的工作项都可以通过过滤项目更轻松地查询）。不过缺点是，这意味着需要两次点击才能获取最新版本。

• 为什么不想保留历史记录？源代码控制的目的是为了保留历史记录，以便你可以回到某个特定日期的某个构建。否则，你可能只需在网络驱动器上使用备份程序（你真的不想那样做！）

• 如果你只担心硬盘空间的使用，那就别担心了。100MB 很小，硬盘很便宜。我的上一个游戏项目有数百 GB 的资产，并且我们保留了每一个更改的历史记录超过 3 年。

• 资产不会减慢任何事情。它们只会在你检入或获取时花费时间，这是你即使不使用源代码控制也需要做的活动。实际上，源代码控制会使事情更快，因为你有一个“一键完成所有操作”的解决方案。

• 源代码控制的许多其他好处对资产真的很有用，远远超过了负面影响。

- Jason Williams

---

好的观点。你真的说服了我。我会尝试在工作中推销它。 - Ofek Shilon