Type List Order Numbers (typelisto​rdernum) change when opening a sequence file in Test Stand

Question

Could you please shed light on the reasons a sequence file changes upon opening in the Test Stand development environment?  
Comparing the file before and after, I see that the typelistordernum changed on a few custom types that we defined for the program. . 
To clarify the environment, I am using two work stations running the same version of Test Stand. The workstations are kept in sync using Sugar Sync. One would expect that a file saved on one workstation could be loaded on the other work station with no change.
This also happens on files that we pull from version control (GIT). Once opened, they change, which presents a serious problem in avoiding version conflicts and keeping track of real changes. 
Test Stand Version: 4.5.1

Answer 1

ATE Coder wrote:
In fact it turns out that conflict resolution is fairly hard to resolve.
For instance, changing a type (add a comment) changes its time stamp. As a result, all sequence files referring to this type are now in conflict.
On testing, Test Stand does not seem to flag these. So, they could be pushed into the repositories as is.
Opening the sequence files on another machine (after pulling to code from repositories), Test Stand detects a conflict that in fact is no conflict at all. Now all these files need to be checked in and pushed up and then pulled down.  This increases the chances of code conflicts many folds and seems to be totally superfluous.
Turning off automatic conflict resolution does not seem to resolve this issue.
It would seem that for some reason (inertia?), NI pulled into Test Stand the same tight versioning it uses in LabVIEW. While in LabVIEW, where, in fact, one is editing compiled code, thins might add some value, Test Stand sequences are actually XML file -- source code, which call for a much more relaxed code versioning or none at all as making sure the code works as part of the debugging process and cannot be handled properly by 'versioning'. 
I think you might not be using automatic conflict resolution the way it is intended.
Are you using type palette files? If not, I highly recommend you do so. If you put the highest version of your types in a type palette file, use the default automatic conflict resolution settings, and distribute or deploy the type palette file to everywhere where the type is being used, you do not have to resave all of your sequence files everytime the type changes. Sequence files with older versions of the type will be automatically updated when they are loaded on machines that have the latest version in a type palette. This is what automatic conflict resolution does, it automatically/silently updates the types in the sequence files when they are loaded. No need to resave everything before hand. If you have trouble getting this working, let me know exactly what you are doing and what problems you are having and I will hopefully be able to suggest an alternative way of managing types that will not have those problems.
Hope this helps,
-Doug