如何防止Unity 3D的库通过外部版本控制继续重建？ [英] How to prevent Unity 3D's library to keep rebuilding itself with external version control?

问题描述

This问题现在大约2岁（对我来说）。当前答案是：无法完成。

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

请记住我正在关注所有手册中加我找到了什么。

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

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

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

• 触摸文件。这里不用理会。触摸得越多，所花费的时间就越多。


• 在Unity之外移动/重命名文件。特别值得注意的是，如果它们是视频文件。


• 保持git中的时间戳是不够的。至少在我可以做到这一点。


• 每当我们在一台新机器上签出时 - 这将添加一个 extra 库重建，因为最终必须改回将平台设置构建到Android或其他任何设备上。 像那样？
  
  
  

  至于一些可能的预期但无效的答案...

  
  
  

  它如果我一起提交库，将无法工作，因为在打开Unity之前检查旧提交并返回到同一个提交也会触发库重建。

  库网络缓存称为缓存服务器并不能解决这些问题中的任何一个。它确实使速度更快，有时特别用于检查新机器。但这还远远不够好。它仍然可能需要长达数小时。
  重建，我只能想象Unity至少在文件上查看时间戳。它可能也在查看树 - 哪些文件存在等，它可能使用内容哈希值，甚至树结构。
  
  
  

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

  如果它有效，它只会允许你有一个窍门 - 检查旧的提交，然后再次检查当前的提交 - 而不会干扰事情。它不会让你直接进行旧的提交，但不需要重建，因为旧的提交不会有时间戳，即使你伪造了旧的文件，新的/移动/移除的文件，校验和等等

  
  
  

  另一种选择是找出Unity在底层的位置，然后将它（或几个）包裹在git回购（或几个）。这可以让你在库重建之前，之中和之后对它们执行 git status ，以查看它实际做了什么。然后，您可能实际上可以将时间戳技巧与第二个记录Unity资产blob（s）的repo混合起来，并将它们编写为一致工作，以防止Unity注意到更改。

  
  
  

  我需要更多信息才能更进一步。几年后我还没有使用过Unity。

  
  

  This issue is about 2 years old now (for me). Current answer is: can't be done.

  I'm using git, but I believe this doesn't depend on which one you're using, even if it's Asset Server.

  Keep in mind I'm following everything in the manual plus what I've found around.

  The library rebuild can take anywhere from minutes to even hours, depending on how much Unity thinks it needs to work.

  Although this is not a critical issue (it doesn't stop the workflow) it's still huge. We're not fully using git thanks to this issue. It's impractical to go back in history to an old commit or even simply changing a parallel branch can become a nightmare. So we always avoid to do it, unless it's critical.

  There are many things that will trigger a library rebuild, here are a few known ones:

  • Touching the file. No brainer here. The more you touch, the more time it takes.
  • Moving / renaming files outside of Unity. Specially noticeable if they are video files.
  • Keeping timestamps in git is not enough. At least in the way I could do it.
  • Whenever we checkout in a new machine - this will add an extra library rebuild because eventually have to change back the build platform settings to Android or whatever.

  The question is in the title: How to prevent the library to keep rebuilding itself like that?

  As for a few plausible expected but invalid answers...

  It wouldn't work if I commit the library along because even just checking out an old commit and back to same one before opening Unity will also trigger a library rebuild.

  The "Library Network Cache" called "Cache Server" does not solve any of these issues. It does make it faster, some times, specially for checking out on a new machine. But it's still far from good. It still can take up to hours.

  解决方案

  As rolling files to an old version, then right back to the most current one triggers the rebuild, I can only imagine Unity is looking at timestamps on the files, at the very least. It's probably also looking at the tree - which files exist, etc., and it might be using hashes of content, or even tree structure.

  It would be interesting to - with Unity closed - copy your entire asset tree to a second location, in a manner that keeps timestamps, then checkout an old commit, then the current one again, then copy the copy back over it, again, keeping timestamps. Then open Unity and see if it wants to rebuild. If it does, I have no idea how it's figuring out that it needs to do this (storing where files reside on the disk, down at the block level?).

  If it works, it will only allow you that one trick - checking out an old commit, then the current one again - without disturbing things. It won't let you just go to an old commit, though, without rebuilding, because the old commit won't have the timestamps, and even if you fake them over the old files, new/moved/removed files, checksums, etc., could spawn the rebuild as well.

  Another option is to figure out where Unity is doing it's thing under the hood, then wrap that (or several that's) in a git repo (or several). This would let you do git status on them before, during, and after library rebuilds, to see what it's really doing. Then you might actually be able to mix the timestamp trick with a second repo that records the asset blob(s) Unity makes, and script them to work in unison to keep Unity from ever noticing changes.

  I'd need more info to go further. I haven't used Unity in a few years.

  这篇关于如何防止Unity 3D的库通过外部版本控制继续重建？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！