# Do I have to commit the downloadable assets for Unity to the repo? Or a reference for the team to download them?

QUESTION (Short version)

I am going to use the Unity Test Tools asset to do unitary testing. Q: Do I have to commit the Unity Test Tools to my repo? (using git, by the way).

CONTEXT

Team / Workflow

• We are an indie team of 10 people (of which 4 coders, 2 graphics, 1 music, 2 marketing, 1 automation-test QA), remotely located.
• We built the team 2 weeks ago, have explored Unity, decided that unity shall be our devel framework, and finally we did an internal silly tic-tac-toe internal for us to check the workflow.
• Now we want to start developing our 1st game. Clean code. Clean repo.
• Using git for version control.
• We configured Unity to write all forced in text and visible metas.
• We are using Unity5 free edition.

Coding

• Up to now, I've managed to create a MVC schema. MonoBehaviour acts as the Controller and then we have non-dependant classes that act as the Model of our game. The controller calls methods of this model. The model throws events to notify the changes in its state.
• We want to unit-test the model.

Assets

• Yesterday I discovered the Unity Test Tools.
• The wonderings presented by this question may happen again if we download other assets or if we want to keep a common own-made library across several games.

QUESTIONS (Long version)

As far as I've seen, assets get "copied" into your project. Okey for working. But... comitting?? I'm feeling uncomfortable.

The same way in PHP you may use composer to handle "dependencies" so if you need a library you do not commit it inside your project, you just commit a text file saying "I want this library, this specific version" -for the sake of example, you can tell composer to install PHPUnit for unit testing, and you commit the composer text file, you do not commmit a full copy of PHPUnit-, these are our questions/wonderings:

Q1) Do I have to commit all the Unity Test Tools in my repo? It is 10 Megas - may seem an overkill or not, depending on your optics... but, as it carries "examples" and I don't know how to filter what is needed and what not, it seems so overkill to me to commit all of it - but worse: this might happen with another asset that is 500 Megas for example. Committing downloadable assets seems anti-pattern. Do I have to commit?

Q2) Or it is better that I don't, and have all the members in the team to manually download the Unity Test Tools?

Q3) If they delete that repo and download it again, the Unity Test Tools seem to be kept local to the project, then a new download is imposed if it's not kept in the repo? Or Unity may store "local in your computer; still global to your projects" things like "the testing library" you are likely going to use in several projects?

Q4) Case one thinks "maybe each project needs its own version of libraries, best practice is do not keep anything global" then, committing them to the project still seems overkill... is there any standard of "config file" that I can place and then once the "git repo" is cloned, run some kind of "dependency installer" or so (much like the composer install action is to a recently cloned repo in PHP)?

I've seeked for information, but I'm still confused on this. I've seen it exists something like an "asset manager" but I'm not sure if this is what I need. Any pointer to documentation I must read will be highly appreciated.

Note that the documentation in Unity website, as for example this one: Mastering Unity Project Folder Structure - Version Control Systems does not address my specific question.

Thanks!

• Just a thought, your question is really "Should I keep downloadable assets for unity in my repo or should each team member download themselves?" If you rename the title I think you may get more attention – Mikael Högström Apr 2 '15 at 8:33
• True, I'll think of a better title. You propose an "or" between two options, while in your second option it is masking a set of two options: "manually download" or "automatically download". I'll take your comment in consideration and I'll rephrase it. Thanks. – Xavi Montero Apr 2 '15 at 9:18

• This is what I want to avoid. "freezing" versions is a "must have". This is exactly what composer does for PHP: You create a composer.json file with your "desires" (for ex: LibraryABC any version 2.* but less than 2.5.22) - then you run a "composer install". Then the system generates a composer.lock text file with the "exact versions" (for ex: LibraryABC version 2.4.37) - the lock file gets committed. This ensures "freezing exact versions" while consuming a 1KB instead of megas and megas. Thanks for the contribution anyway. – Xavi Montero Apr 2 '15 at 9:22