How do I best handle a Teststand Environment with Source Code Control?

[David_Grucza]

I'm going to answer this question myself, but my intent is to see if anyone has a better answer. My answer is based on Git, but any other SCC will likely be similar.

My Answer: .gitignore any folders and files I'll never need and then track everything else, even files that are never modified. If a file is ever marked as modified, stage it and try to remember what I did to cause it to be modified so I can enter a meaningful commit comment (Sometimes that will be obvious, other times not).

My reasoning:

• I can't simply delete unneeded files because Teststand will recreate them when I open the environment.
• I can leave them in the Teststand environment untracked by Git. But I won't have an easy way of knowing if something I did caused one to be modified.
• I can git-add them all and only commit modified files. But that is really cumbersome.

Additional Info:

I created a Teststand environment with all three folders: CommonAppData, LocalAppData, and Public. These are in sub-folder of a VS Code workspace folder along with the .tsenv file.

 
    ├───vs_code_workspace_folder
    │   └───teststand_environment
    │       │   .gitignore
    │       │   project.tsenv
    │       ├───CommonAppData
    │       ├───LocalAppData
    │       └───Public

The first thing I do is .gitignore anything I will never need. I'm using the TS Python adapter, so I can ignore the CVI and LabVIEW adapters. I also likely don't need to track LocalAppData, but since it has NIERDump I think I want a project specific folder. But I don't fully understand what is in all of these folders, so one questions is: What do I absolutely not need in SCC?

My .gitignore file

CommonAppData/Cfg/SeqEdit/
LocalAppData/
Public/AdapterSupport/CVI/
Public/AdapterSupport/LabVIEW/

Some files I need to track:

• StationGlobals.ini

• Adapters.config

• MyTypes.ini

• Any custom type palettes
• Lots of other files that are modified as I change settings in the TS Development GUI

[Oli_Wachno]

Hi David,

I guess, this really depends on your use case, especially if you are working with an own framework with different components and the way you want to set up your actual Testprograms (an own environment for each, for some, common for all)

I have been thinking through this over and over again regarding modularity of the framework, especially with the technical possiblities, that SVN (we're still using this) offers ...

No silver bullet I am aware of...