Parameter conflicts, not resolved after the first stage, fixed by default git tools.Objects combined on the scene with UnityYAMLMerge, so you can use an editor to resolve it.Respectively, their solution divided into two stages: We can divide such conflicts in Unity into two constituent: conflicts of objects and conflicts of parameters. Still, it is a bit concise and does not focus on the essential aspects of its use, which we will analyze in detail. Documentation provides all the necessary information on using the tool. To resolve conflicts with scenes and prefabs, Unity offers to use a utility called UnityYAMLMerge. In Unity, this problem is fully applicable to the scenes and prefabs. In the previous article, 'Custom Elements in the Unity Editor,“ we briefly mentioned the problems that may arise when using all sorts of visual editors in a distributed manner, such as blueprints in Unreal. At first only the 'Bundles' is different and then rest of the bundles become different machine to machine in time.Since I did not manage to commit before my comrade, it’s time to fulfill the promise given in the article about configuring git to work with Unity and figure out how to use UnityYAMLMerge to resolve the conflicts. In my previous experiences the problem will grow in time. build bundles (sprites.bundle is same, Bundles and Bundles.manifest generated with CRC_NEW, identical with Slave-1) clone repo (do not sync timestamps, open from UI, switch to android from Build Settings) build bundles (sprites.bundle is same, Bundles and Bundles.manifest generated again with CRC_OLD) build bundles (sprites.bundle is same, Bundles and Bundles.manifest generated with CRC_NEW old CRC_OLD) check timestamps (identical with master) clone repo (open from command line with -buildTarget android) import 2 sprites assign a bundle name (sprites.bundle) use gitignore and gitattribute files (attached to post) Is there any possible cause you can suggest? Ok, so the svn stands out as a possible source of the problem:Ĭlick to expand.I do some playground, I think timestamps are irrelevant. WebExtract & binary2text are found in the Unity install location under the Data/Tools directory. If you post or direct message that information I can definitely look over it (note: on vacation next week) and see if it is something we have fixed, or still need to fix. Then run DiffMerge again on the text files and you can then see exactly what changed. If they are different, you can use WebExtract on the bundles to pull out the internal content, then run binary2text on the extracted internal content to get a more human readable version of the bundle data.

Use a diff application like DiffMerge to check the 2 bundle files and see if they are the same or different. If that is still the case, then that would make the asset hash calculation system mess up again and make it think the asset has changed.įinally, I'd also test to see if the bundles themselves are actually different run to run. Timestamps are also a big deal with SVN as from what I remember SVN tends to mess up the timestamps of when the asset was last modified. So if your SVN is modifying the line endings to match the platform, that will mess up the hash calculation and make it think the asset has changed and thus need a rebuild. Unity uses unix line endings when it writes out any text files, regardless of platform.

This will definitely cause the asset hash to be different in certain cases.

Make sure your SVN does not modify the line endings of any text files on checkout. Click to expand.Ok, so the svn stands out as a possible source of the problem:

Using diffmerge wtih unity