Bug Tilemap wrongly altered after merging scenes with Smart Merge

Hello !

We have an issue with tilempaps which get partly messed up sometimes after a scene merge with Smart Merge (UnityYAMLMerge, through Plastic SCM). It doesn't happen often, fortunately, but when it does, it can be painful to fix (finding an older tilemap version, manually reproduce the changes, etc).

At first we thought it was a human mistake, like accidently using the fill tool (because it is often a tile which gets repeated for some reason). And sometimes the problem isn't visible right away.

But our last tilemap issue now proves the merging went wrong:

The changesets in Plastic SCM:


Tilemap in changeset #1 (Chset1):


Tilemap in changeset #2 (Chset2, nearly identical)


The only manual merge I had to do (a component was removed, nothing to do with tilemaps)


And the result of the merge (we didn't get any error in the log when opening the scene) :



So yeah, this is really strange. As you can see tiles get messed up (removed or repeated several times). We only get tilemaps issues in our scenes when merging what both of our level designers did on their side. Also, in this particular case, if any changes were done to a tilemap it would be only on the branch which was merged.

So... Are tilemaps supposed to be mergeable, or should we never merge them ? Is this a bug in the way tilemaps save their data ? Did anyone else experience this issue ?

 

I treat YAML as fundamentally unmergeable.

The reason is that changes to a single GameObject are actually interleaved throughout the file. Try it yourself and see in the diffs.

With a single Tilemap you're kinda stuck. Otherwise the solution is always to break scenes into lots of smaller scenes (additively loaded), as well as to aggressively use prefabs that are NEVER emplaced in the scene but only loaded dynamically.

One useful technique for sharing larger assets is to maintain a shared Google Sheets doc listing each of the scenes (or large prefabs) that you suspect may be edited by more than one person on your team, and then have people go there FIRST to mark it as "mine" before manipulating and committing them.

If you're all in the same room, buy a dozen little yellow rubber ducks and write the name of each scene on the side of them.



Of course, this approach completely fails with long-lived branches.

One approach for long-lived branches is to actually duplicate the scene or prefab intentionally, and then work separately, knowing that ultimately you WILL have to do a final manual merge. This can be a mess if you're interleaving lots of stuff, but if one guy is working on sculpting the ground and another guy working on placing enemy spawnpoints, it can still work to hand-merge all at once at the end of the branch life.

 

Thanks for your response !

Yup, that's kind of what we actually do, a dynamic load of prefabs at runtime of all entities, making the scene file smaller which is also better for the merge And we never get issues with those elements, so I agree it's a good way to treat prefabs.

Thanks! I see how these ideas can be practical in some context, but I don't think they will work for us (too high maintenance I think); We use a very simplified version of SCRUM with Trello, works well most of the time). Also we try to work on short-lived branches to make merging as easy as possible, so we can prevent having to duplicate scene files

I just don't understand why, sometimes, we get these strange results on tilemaps after a merge. Because most of the time merging works well and I think we save lot of time making our game the way we do.

In any case, I appreciate you taking the time to respond.
Cheers!