07-25-2012 08:21 PM
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
07-26-2012 08:24 AM
My guess is that the types are changing. You can verify this by going to Configure>>Station Options and on the File tab change the Allow Automatic Type Conflict Resolution to Never. Then open your file and see if you get the type conflict dialog.
This will happen when you open an older sequence file with a newer version of TestStand.
07-26-2012 10:22 AM - edited 07-26-2012 10:24 AM
The typelistordernumber changing means that the order of the types in the file, as shown in the Type Palette document of the sequence editor has changed. This could change if your remove all instances of a type from the file, such that the type will then also be removed and thus the order number of types after that in the type list will be decremented.
-Doug
07-26-2012 10:51 AM
Thanks, Guys -- both your comments are right on. I did turn off automatic version conflict resolution.
It seems that the automatic version conflict resolution mostly raises false alarms. It would have been so much more prudent to point at the potential conflicts rather than tag file hosting the types as changed.
I also am puzzled at the value of keeping track of the type ordering in the type file. What purpose does that serve?
07-26-2012 02:52 PM
The typelistordernumber is needed in order to restore that order when loading the file. The types in the file are saved in dependency order in order to optimize file loading, so that the file can be read sequentially in one pass.
I'm not completely following what you mean for the automatic conflict resolution case. Since the types are saved in the file, if a type changes, then the file has been modified. There are no false alarms that I am aware of, either the type has changed or it hasn't.
-Doug
07-26-2012 04:34 PM
Loading order, ha? Should we ask NI to move loading order to the .opt file? That way non breaking changes will affect only the changed files.
Note that editing comments changes the types. Most changes can be said to cause no 'conflict' (depending, of course, on how conflicts are defined).
One operational question is: does it make sense for all files in a project to change if one file has a non breaking change such as a changed comment?
07-30-2012 08:57 PM
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'.
07-31-2012 08:57 AM
@ATE Coder wrote:
Loading order, ha? Should we ask NI to move loading order to the .opt file? That way non breaking changes will affect only the changed files.
Note that editing comments changes the types. Most changes can be said to cause no 'conflict' (depending, of course, on how conflicts are defined).
One operational question is: does it make sense for all files in a project to change if one file has a non breaking change such as a changed comment?
For type order changes:
If you changed the order of local variables in a sequence would you also not want that reflected in the sequence file and instead saved in an .opt file? I'm not understanding why it's unexpected for the order of the types to be saved in the file, it is after all related to the data stored in the file. Perhaps I am missing something. If so please explain why this is different. What is your use case for which this leads to problems? If you are having problems because you are diffing the files in a text differ, I'd recommend you use the teststand file differ instead.
For adding comments:
I see how making a minor change to a type and having that propogate to all files might be inconvenient. However you don't have to resave files which use the type unless you have some other reason for doing so. As long as your type is in a type palette file, the type conversion will get done every time the file is loaded.
-Doug
07-31-2012 09:04 AM
@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
07-31-2012 10:45 AM
Hi Doug,
Thanks for your help.
The types do reside in type palette file, which is part of the project. Indeed, the type resolution happen but this is far from silent :). Obviously, after resolving what test stand perceives as a conflict, the sequence file changes. Now imagine this in a version control system. Two stations were updated and all files get changed for no apparent reason with the programmer having any clue as to what specific changes took place. Nice, right?
Now you may say why save the file. Is this really a viable solution? Those files will have to be edited at some point at which time a conflict will ensue which source is unknown.
Does this type resolution not seem to you like a solution seeking a problem?
David