2

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.

Community
  • 1
  • 1
cregox
  • 17,674
  • 15
  • 85
  • 116

1 Answers1

0

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.

Gary Fixler
  • 5,632
  • 2
  • 23
  • 39
  • Yes, sorry. I copied my old question and, although I've updated it a bit, I've overlooked the known triggers. Updated that too, now. About your suggested test, I hope it's clear in the update, but for the "trick" part (3rd paragraph), how would that be of any use? Yes, figuring out what Unity is doing under the hood is one answer I'd expect. As for the "more info", you may have to use unity to be better able to answer this. In any case, thanks for bringing up my lack of updates! :) – cregox Sep 13 '13 at 14:59