2

这个问题现在大约有 2 年了（对我来说）。目前的答案是：做不到。

我正在使用git，但我相信这并不取决于您使用的是哪一个，即使它是 Asset Server。

请记住，我正在关注手册中的所有内容以及我在.

库重建可能需要几分钟甚至几小时，这取决于 Unity 认为它需要工作多少。

虽然这不是一个关键问题（它不会停止工作流程），但它仍然很大。由于这个问题，我们没有完全使用 git。回到历史中回到旧的提交是不切实际的，甚至简单地更改并行分支也可能成为一场噩梦。所以我们总是避免这样做，除非它很关键。

有很多事情会触发库重建，这里有一些已知的：

  • 触摸文件。这里不用多说。触摸的次数越多，花费的时间就越多。
  • 在 Unity 之外移动/重命名文件。如果它们是视频文件，则特别引人注目。
  • 在 git 中保留时间戳是不够的。至少在我能做到的方式上。
  • 每当我们在一台新机器上结账时——这将添加一个额外的库重建，因为最终必须将构建平台设置更改回 Android 或其他任何东西。

问题就在标题中：如何防止图书馆继续这样重建自己？

至于一些看似合理的预期但无效的答案......

如果我同时提交库，它将无法正常工作，因为即使只是在打开 Unity 之前签出旧提交并返回相同的提交，也会触发库重建。

称为“缓存服务器”的“图书馆网络缓存”并不能解决任何这些问题。有时，它确实使它更快，特别是在检查新机器时。但这还远远谈不上好。它仍然可能需要几个小时。

4

1 回答 1

0

由于将文件滚动到旧版本，然后回到最新版本触发重建，我只能想象 Unity 至少正在查看文件上的时间戳。它可能还在查看树 - 存在哪些文件等，它可能正在使用内容的散列，甚至是树结构。

有趣的是 - 在 Unity 关闭的情况下 - 以保留时间戳的方式将整个资产树复制到第二个位置，然后检查旧提交，然后再次检查当前提交，然后再次将副本复制回它，保持时间戳。然后打开Unity，看看是否要重建。如果是这样，我不知道它如何确定它需要这样做（将文件存储在磁盘上的位置，在块级别下？）。

如果它有效，它只会允许你使用一个技巧——检查一个旧的提交，然后再次检查当前的提交——而不会干扰事情。但是，它不会让您只进行旧提交，而无需重建，因为旧提交不会有时间戳，即使您在旧文件、新/移动/删除文件、校验和等上伪造它们.，也可以产生重建。

另一种选择是弄清楚 Unity 在哪里做这件事，然后将它（或几个）包装在一个 git repo（或几个）中。这将让您git status在库重建之前、期间和之后对它们进行操作，以了解它真正在做什么。然后，您实际上可以将时间戳技巧与记录 Unity 制作的资产 blob 的第二个 repo 混合使用，并编写脚本让它们协同工作，以防止 Unity 注意到更改。

我需要更多信息才能走得更远。几年没用过Unity了。

于 2013-09-13T06:57:15.890 回答