Most efficient way to clean a project

[RTSLVU]

I have a large project that wrote several years ago. I have been the sole writer, contributor and maintainer of this project. I have made several changes and improvements over the years, Usually making a new copy of a sub-vi before modifying it. So now I have several years worth of older vi versions in my project hierarchy.

What is the most efficient way to clean this project so the hierarchy only contains sub-vi versions that are currently in use? 

[jcarmody]

I've resorted to creating a source distribution, then making a new project in the output folder.

[Kyle97330]

I once wrote a VI that did the following:

1. Took in a list of "Main" VIs present in a project (which could be just one)

2. Got a list of all dependencies of that VI recursively

3. Made sure to include any files that were dependencies by association (such as all class members, all possible descendant classes)

4. Went through the list to ensure it was a complete list of files on disk (for instance, if a file was in a LLB, it only referenced the LLB file)

5. Compared that list against a defined root folder on disk, disregarding any located elsewhere

6. Got a recursive file listing of that same root folder on disk

7. Looked for any files that were in the root folder but not in the list of dependencies on disk

8. Took the list of all those files and deleted them.

I would then close everything, re-open the main project and main VIs, and confirm that none of the main VIs were broken or searched for files on startup.  If anything was reported as missing (somehow having passed through all the scripting and filters) I would restore it from source control.

(If you don't have source control, start using it!)

[crossrulz]

---

@RTSLVU wrote:

I have a large project that wrote several years ago. I have been the sole writer, contributor and maintainer of this project. I have made several changes and improvements over the years, Usually making a new copy of a sub-vi before modifying it. So now I have several years worth of older vi versions in my project hierarchy.

---

Just to keep beating the dead horse, Source Code Control is the tool to avoid this happening to you. GIT is the most commonly used SCC out there, followed by SVN.

With that said, first thing you do is get your code into an SCC. Initially, this is a backup just in case you completely mess something up. After that, I would say creating a source distribution is the next thing to do, with just your top VI(s) explicitly called out. After "building" that, you should have only what is required. Test it to verify it still works. Finally, commit your updates to your SCC repository.

[crossrulz]

---

@RTSLVU wrote:

What is the most efficient way to clean this project...

---

My tongue-in-cheek response: Ctrl+A, Delete, Ctrl+S

[raphschru]

---

@crossrulz wrote:

---

@RTSLVU wrote:

What is the most efficient way to clean this project...

---

My tongue-in-cheek response: Ctrl+A, Delete, Ctrl+S

---

I guess what you mean is doing Ctrl+A and Delete from the file explorer, then "Save All (this Project)" from LabVIEW?

I don't think LabVIEW will like that, there will be lots of "[Warning: has been deleted, renamed or moved on disk]".

What about right-clicking your project root > Find Items with No Callers ?

You can even export its output to a text file and input it to a script that would delete them by path.

Make sure to remove/filter the VI paths that you don't want to delete though, as it will contain the top-level VI(s) as well.

Regards,

Raphaël.

[Jacobson]

One thing I've found helpful is to open your project and then drag the "source" folder for the project from the windows explorer into your project. A lot of virtual folders may be created but LabVIEW will only add files if they aren't already in the project. This is an easy way to find orphaned VIs without any additional tooling.

[raphschru]

---

@RTSLVU wrote:

I have several years worth of older vi versions in my project hierarchy.

---

@Jacobson wrote:

One thing I've found helpful is to open your project and then drag the "source" folder for the project from the windows explorer into your project. A lot of virtual folders may be created but LabVIEW will only add files if they aren't already in the project. This is an easy way to find orphaned VIs without any additional tooling.

---

I may have interpreted wrong, but it seems @RTSLVU is talking about uncalled VIs already in the project.

[RTSLVU]

---

@Kyle97330 wrote:

(If you don't have source control, start using it!)

---

@crossrulz wrote:

---

---

Just to keep beating the dead horse, Source Code Control is the tool to avoid this happening to you. 

Speaking of beating a dead horse. I have been asking for access to our source control for over a decade. Those snooty software and firmware group managers don't believe my work is important enough to be allowed to use their precious tools. 

When I leave this company they could be screwed.

I have long since come to the conclusion that if management doesn't care, why should I?

[crossrulz]

---

@RTSLVU wrote:

Speaking of beating a dead horse. I have been asking for access to our source control for over a decade. Those snooty software and firmware group managers don't believe my work is important enough to be allowed to use their precious tools. 

When I leave this company they could be screwed.

I have long since come to the conclusion that if management doesn't care, why should I?

---

Even SVN just on your computer or a network drive (perhaps a project network folder) will be helpful. And you should care because it is to make your life easier.