pscheper wrote:

I provided an answer in the post you shared: https://developer.vuforia.com/forum/issues-and-bugs/v10-puts-420mb-binaries-source-control#comment-74187

I know, and appreciate it. However, it is still a real issue.

Quote:

"I have not been able to reproduce the issue where there's a second tarball (.tgz) file is inside Assets/Editor/Migration/.

Yeah I'm not sure what triggers things to go in Migration; although I have found that the copy there can be safely removed. Fwiw, though 220MB, 240MB, 480MB, doesn't matter, it's all a problem.

Quote:

This approach was chosen by our R&D due to the fact that developers had issues adding Vuforia Engine to their projects with Git.

due to the fact that developers had issues adding Vuforia Engine to their projects with Git user error by the developers followed by failure to solve the issue and an incorrect conclusion that said issue was unsolvable, with a nonsensical reason to justify it. I've been around the block and you probably have, too. We both know how programmers minds work on dev teams. Plus, Vuforia is literally the only package I've ever seen that uses this "package management" strategy; another good hint that the devs were doing something wrong when they first tried to set this up and determined that they "couldn't".

Quote:

This is supposed to make it easier to import Vuforia Engine,

Easier than what, adding a repo to the Unity package manager and clicking "import"? This is Unity, interacting with the package manager is a normal occurrence. It doesn't need to be made "easier", especially when the attempt makes it more difficult.

Plus...

Quote:

... especially with developers using version control systems.

Essentially means any developer using Vuforia in any real capacity, especially these days when virtually everybody uses source control, especially GitHub.

So somebody really needs to get on the devs cases and get this switched over to the usual package management strategy that everybody else besides Vuforia uses.