Hey everyone,
One of my teams recently added the Unity Smart Merge tool to the settings in PlasticSCM. I have another project that is on a different version of Unity, where as the command line here specifies version 6000.0.34f1.
Will this cause a problem when I check in or merge something in the other project that is under a different version?
Thanks very much
Please move the custom merge tool above in the list so it has more priority than the $text and $binary options.
If the path for the external merge tool exists on disk in the machine you are running the merge, it shouldn’t be a problem.
Would you mind clarifying what that means? I would be super happy if I can confirm it is fine, but I just want to be extra safe. Thanks
I am also interested in clarification on how it chooses which rule to use. Are you saying if $text and $binary are above any custom extensions in the list, those custom extensions will never trigger a different tool? I had always thought it operated on most to least specific.
Edit: Somewhat answered my own post. No, it does not go most to least specific, which is unfortunate. I think a lot of our users have been not using UnityYAMLMerge for a long time because of this. Which… is bad. This is a bit of a UI trap, since all extensions that are added will by default appear at the bottom of this list. I feel like $text and $binary shouldn’t be in that list but should be a separate box. It just doesn’t make sense to have it designed this way.
It means that you put your custom merge tool first on the list.
Otherwise, the $text or $binary merge tools will be used instead.
When you have multiple merge tools for the same file type, the first on the list will be used.
I think it’s necessary to define some general tools for $text and $binary, but we should make the tool priority order clearer. Let me share this feedback with the dev team.
