Git Ignore On Addressableassetsdata Or Streamingassets ?

I was wondering if it's safe to add either of these directories to my .gitignore?

After doing a build, I find I end up with a change to Assets\AddressableAssetsData\addressables_content_state.bin. That's fine, but it's weird to do a build and generate versioned changes in the process. Is everything in AddressableAssetsData generated? Can I safely ignore it?

The same goes for StreamingAssets. It's already starting to generate some relatively large files, and I'm concerned it could create some very large files some day, which would cause issues trying to commit large files to version control. Is it safe to git ignore StreamingAssets and just let unity generate that content?

Thanks.

 

the breakdown:
`Assets\AddressableAssetsData\addressables_content_state.bin` - this one file can be ignored from version control until you do a real build and have a server. the purpose of that file is to handle content updates. So depending on your setup, you can ignore it or not.
`Assets\AddressableAssetsData\` - everything else in this folder needs to be in version control. this is all your data. if you don't save this, you don't save anything about addressables.
`Assets\StreamingAssets` - in the upcoming 0.7.x release we're going to stop putting stuff here. All the file that we need to be there will actually be staged in the Library. In play mode, we'll look directly at the Library. During a build, we'll copy what we need over, build, then delete.

 

Thanks very much. I'm deploying via Steam, so it sounds like I don't need to worry about addressables_content_state.bin. I appreciate the details on the other files.

 

In my case I have an asset named "addressables_content_state.bin" inside some iOS folder that gets created and removed all the time depending the os. All devs have all modules (iOS, Android, etc) installed but for some reason that folder related assets get created/removed all the time. Is it safe to ignore in git? is it inside the AddressableAssetsData and you said everything inside that folder should be in version control. Also we are using the latest addressables package.

 

That file is generated every time you do a "build player content". The only way I could imagine it getting removed by us is if we deleted it at the beginning of a build, then the build failed.

Should it be in version control? depends. That file is a record we keep of the assets in the build and the name of the catalog. The only purpose it serves as a basis for doing content update builds. Both "prepare for content update" and "build for content update" need that file. So you can ignore it unless it was created during a content build used in a player build you intend to update. This would either be a player build you actually ship, or in the case of doing editor-hosted iteration, a build you've deployed to a test device.

 

Ok, thanks! will ignore it for now and consider changing back if we try updating content.

 

Hey, getting pretty confused about this. I'm new to addressables so maybe I'm missing some context.

I'm finding that this file gets recreated (and is different) every time I build addressables despite not having made any changes. Does the file contain something non-deterministic like a timestamp, or is the build process actually non-deterministic? If it's not deterministic, does that mean we need to retain the _exact_

addressables_content_state.bin

that was used to make the last build if we want to make a content update?

To me the question of whether this should be ignored is more about whether it's important that my team-mate gets the copy of of the file that my editor generated when I last built. Is this the case? Or do we just commit it when we build a release?

As some general feedback it would be handy for all the

Assets/AddressableAssetsData/<Platform>/

paths to be nested under a folder that can be ignored en-masse. The way it's laid out now we need to ignore

/Assets/AddressableAssetsData/*

and then make exceptions for files that are retained. It would be more convenient to ignore e.g.

/Assets/AddressableAssetsData/Platforms/*

This is the ignore pattern I ended up with:

Code (csharp):

1.  
2. # Ignore unnecessary addressable build artifacts
3. /Assets/AddressableAssetsData/*
4. !/Assets/AddressableAssetsData/AssetGroups/
5. !/Assets/AddressableAssetsData/AssetGroups.meta
6. !/Assets/AddressableAssetsData/AssetGroupTemplates/
7. !/Assets/AddressableAssetsData/AssetGroupTemplates.meta
8. !/Assets/AddressableAssetsData/DataBuilders/
9. !/Assets/AddressableAssetsData/DataBuilders.meta
10. !/Assets/AddressableAssetsData/*.asset
11. !/Assets/AddressableAssetsData/*.asset.meta
12.  

 

Another way to ignore

addressables_content_state.bin

is:

# Packed Addressables

/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*