我们如何快速高效地进行Yaml合并

In Unity 5.0, we shipped the scene and prefab merge tool, and It’s been positively received by the Unity Community. However, we’ve since realized that it doesn’t handle large scenes optimally, especially with respect to memory usage and the time taken to execute processes.

在Unity 5.0中，我们提供了场景和预制合并工具，并获得了Unity社区的好评。 但是，我们此后意识到，它不能最佳地处理大型场景，尤其是在内存使用情况和执行过程所花费的时间方面。

We’ve now worked on a number of changes to improve this, and they will go into future Unity release. As a result, the system is both more memory efficient and faster than other popular merge tools. Here’s a look at what we did.

现在，我们已经进行了许多更改以改进此更改，这些更改将在将来的Unity版本中使用。 结果，与其他流行的合并工具相比，该系统在存储效率和速度上均更高。 看看我们做了什么。

10英里概览 (How it works 10 mile overview)

This is roughly how the tool worked to begin with: Three files are read from disk (e.g. mine, incoming and base scene/prefab files) into an in-memory yaml structure exactly like the one we have inside Unity itself.

这大致就是该工具的工作方式：从磁盘读取三个文件(例如，矿山，传入和基础场景/预制文件)到内存中的yaml结构中，就像我们在Unity自身内部拥有的结构一样。

Now a diff is made between mine and base, and that results in a form of diff-tree describing which operation to perform on the base version yaml to get to the mine version yaml (mine/base diff). The same diff-tree is created for incoming and base (incoming/base diff).

现在，在我的和基础之间进行了区分，这形成了差异树的形式，描述了要对基本版本yaml执行哪个操作以获取到我的版本yaml (mine / base diff) 。 为传入和基准 (传入/基准差异)创建相同的差异树。

The two diff-trees are now merged into one unified diff-tree (merged diff). This is the first point where conflicts can happen and the conflicts can be resolved by the user. Since the merged diff consists mostly of content from the two source diffs it simply references data inside the source diffs and we make sure their lifetimes exceed that of the merged diff-tree. After this merge is done the source diffs are considered invalid because they may have been rearranged during the merge.

现在，将两个差异树合并为一个统一的差异树(合并的差异)。 这是可能发生冲突并且用户可以解决冲突的第一点。 由于合并的差异主要包含来自两个源差异的内容࿰