LabVIEW Project and File Explorer Synchronization for Version Control

[CaseyN21]

Hey folks,

I haven't seen this topic brought up lately so I thought I would ask it again. How are you all organizing your LabVIEW project files (VI, controls, etc) in your file explorer folders (directories)? I am finding it difficult to prevent old VI's from riding along in project improvements with version control (GIT). In other words, say I remove a VI from my top level VI in my project; all the VI's and subVI's are still in my file explorer folder. What's your method to prevent this besides actually going through each folder and deleting each VI? Can auto-updating folders delete VI's from your file explorer folder?

Thanks,

-Casey

[Bob_Schor]

First of all, do not turn on Auto-updating (except, perhaps, "momentarily" to pull into the Project files you meant to include, but then, turn it off again).  [Or at least this is what I do, and I recall deciding on this, or reading about this being a "Good Idea" on the Forum maybe 5-6 years ago].

I'm of the school that ontogeny recapitulates phylogeny the physical folder structure should match the (Project's) Virtual Folder structure.  So whenever I do a "Remove from Project", I go to Windows Explorer and delete the file, too.

Sometimes this gets tedious (and you might worry about "wanting it back next week".  So make a physical folder in your Project called "Obsolete" and add it to your Project.  Now, instead of doing a Remove from Project, first move the offending VI into "Obsolete" and then Remove from Project (or not, your choice).  Once you are certain you don't need it (and the 20-30 other "discards", you can empty the physical folder of its files, and do the same in the Project.  [This is something that I do].

Bob Schor

[billko]

---

@Bob_Schor wrote:

First of all, do not turn on Auto-updating (except, perhaps, "momentarily" to pull into the Project files you meant to include, but then, turn it off again).  [Or at least this is what I do, and I recall deciding on this, or reading about this being a "Good Idea" on the Forum maybe 5-6 years ago].

I'm of the school that ontogeny recapitulates phylogeny the physical folder structure should match the (Project's) Virtual Folder structure.  So whenever I do a "Remove from Project", I go to Windows Explorer and delete the file, too.

Sometimes this gets tedious (and you might worry about "wanting it back next week".  So make a physical folder in your Project called "Obsolete" and add it to your Project.  Now, instead of doing a Remove from Project, first move the offending VI into "Obsolete" and then Remove from Project (or not, your choice).  Once you are certain you don't need it (and the 20-30 other "discards", you can empty the physical folder of its files, and do the same in the Project.  [This is something that I do].

Bob Schor

---

I'm just the opposite.  I prefer a fairly flat physical structure and do most of my organizing in the project, itself.  This was mostly done because I tend to run into the Windows path length issue otherwise.  I don't really see a problem with this because you shouldn't be opening a VI outside its project anyway.

I don't particularly worry about wanting a file back later.  Once committed - at least in SVN - it's there forever and you always get it back.

[wiebe@CARYA · Accepted solution]

I make my class hierarchy the same as my directory hierarchy. Children in sub folders.

All my projects are completely auto populating.

If I remove a Vi from my project, I delete it from file. If I want to keep it, I either move it outside my project scope, or trust SCC where it stored.

I have long paths. but haven't run into path length problems (yet).

[crossrulz]

---

@Bob_Schor wrote:

First of all, do not turn on Auto-updating...

I'm of the school that ontogeny recapitulates phylogeny the physical folder structure should match the (Project's) Virtual Folder structure...

---

That seems contradictory.  The Auto-populating folders in the project was designed for that exact purpose.

Personally, I have a folder for each library or class.  Inside of those folders is a flat directory hierarchy.  But I then use Virtual Folders in the project to organize the code.  When I no longer need a VI, I will go delete it in Windows Explorer.  If that was a mistake, well that's was SCC is for (SVN or GIT, depending on the project).