03-02-2021 05:24 PM
I inherited an existing set of LabVIEW 2017 code with the file naming scheme to include a version number in many files. For example, if we are on version 3, things are stored on local disk like this,
The directory TopDirVersion3\DirectoryForSomeFunctionVersion3\ contains
SomeProjectVersion3.lvproj
SomeProjectVersion3.lvlps
SomeProjectVersion3.aliases
TopDirVersion3\builds\DirectoryForSomeFunctionVersion3\ contains
SomeProjectVersion3.aliases
SomeProjectVersion3.exe
SomeProjectVersion3.ini
TopDirVersion3\DirectoryForSomeOtherFunctionVersion3\ contains
SomeOtherProjectVersion3.lvproj
SomeOtherProjectVersion3.lvlps
SomeOtherProjectVersion3.aliases
TopDirVersion3\builds\DirectoryForSomeOtherFunctionVersion3\ contains
SomeOtherProjectVersion3.aliases
SomeOtherProjectVersion3.exe
SomeOtherProjectVersion3.ini
I checked Version3 out of source control and made changes to many of the files. Now I want to make a new version: wherever "Version3" appears in a filename or directory name, including TopDirVersion3, I want to replace it with "Version4". Here are my guesses how to do this,
There are vi's, ctl's, and other files without Version3 in their filenames under TopDirVersion3. I think I can just leave them alone once I've renamed the directories they are in to Version4.
How many of these guesses are wrong?
Due to backward compatability, I need to keep this file naming scheme.
Solved! Go to Solution.
03-02-2021 05:40 PM
@colorimeter wrote:
I inherited an existing set of LabVIEW 2017 code with the file naming scheme to include a version number in many files. For example, if we are on version 3, things are stored on local disk like this,
The directory TopDirVersion3\DirectoryForSomeFunctionVersion3\ contains
SomeProjectVersion3.lvproj
SomeProjectVersion3.lvlps
SomeProjectVersion3.aliases
TopDirVersion3\builds\DirectoryForSomeFunctionVersion3\ contains
SomeProjectVersion3.aliases
SomeProjectVersion3.exe
SomeProjectVersion3.ini
TopDirVersion3\DirectoryForSomeOtherFunctionVersion3\ contains
SomeOtherProjectVersion3.lvproj
SomeOtherProjectVersion3.lvlps
SomeOtherProjectVersion3.aliases
TopDirVersion3\builds\DirectoryForSomeOtherFunctionVersion3\ contains
SomeOtherProjectVersion3.aliases
SomeOtherProjectVersion3.exe
SomeOtherProjectVersion3.ini
I checked Version3 out of source control and made changes to many of the files. Now I want to make a new version: wherever "Version3" appears in a filename or directory name, including TopDirVersion3, I want to replace it with "Version4". Here are my guesses how to do this,
- It is tempting to just rename them on disk, but here it sounds like that's wrong; yet I'm worried that if I do it from inside the Project Explorer, things under TopDirVersion3 will still be in memory and be cross-linked.
- Can I delete all "builds" subdirectories under TopDirVersion3 and just regenerate the builds once I have TopDirVersion4 and all its contents using Version4 in their name?
- Can I delete all lvlps and aliases files under TopDirVersion4?
There are vi's, ctl's, and other files without Version3 in their filenames under TopDirVersion3. I think I can just leave them alone once I've renamed the directories they are in to Version4.
How many of these guesses are wrong?
Due to backward compatability, I need to keep this file naming scheme.
This is a BAD IDEA. You already have versioning software for exactly the reason you want to rename all these files. Instead of doing that, just look at the file's versioning properties. Who is responsible for this workflow? Someone who doesn't understand versioning software, I guess. I'm guessing that all that renaming is to have a history of sorts for all your files. But by constantly renaming files, you destroy the versioning software's ability to do that automatically. That workflow is generating a LOT of unnecessary churn...
03-02-2021 05:58 PM
Your workflow also wastes ungoldy amounts of disk space, as each file is considered new and therefore saved in the repository. If you think the repository is taking a snapshot of your working folder, you're wrong. It is comparing what it has to what you have, and only saves what's different. If everything is different all the time, you actually DO end up taking a snapshot of the entire folder, and when you have hundreds of VIs in your project, that just eats up space like crazy.
03-04-2021 11:01 AM
We have a "one LabVIEW programmer" mode and so this was handed to me as is.
Thank you for highlighting the disadvantages to our present setup. As a LabVIEW novice trying to put out the fire of cleaning up cross linkages in this code so it can run again, also being new to source control, I will need to postpone the big cleanup. But at least I know I need to do it.
03-04-2021 11:45 AM
Can you convince the "authority" to let the repository keep track of the changes so you don't have to? (i.e., just keep the names the same and let the repository handle the revisions.)
03-04-2021 11:52 AM - edited 03-04-2021 11:53 AM
Basically, as long as I later release a new version of the exe files that can be distinguished by novice users from the old version that they need to stop using, no one cares how this is done. It is up to me to figure it out. The obstacle is that I am green in too many areas at once to do any major reworking.
03-04-2021 01:11 PM
A couple things you can do.
First, the version number is a setting in the EXE build, and would show up in the details when you look at the properties of the .exe file. Of course that means someone needs to periodically take the time to look for it. You should also build your own About dialog box that would include your version number, so that Help, About... will tell the version.
If you need someone to know right away a new version exists, have the exe check against a common network location versus its own version number. If it finds a new version on the network, it can throw up a dialog and you can continue as is, or the person can stop and download the new version.
Something our IT person did with a VB based program is that he released two programs, a loader and the real program. The loader does the check to see if a new version is available. If your local version is up to date, it proceeds to load the local exe and closes itself. If there is a newer version, the loader downloads the new exe overwriting the old, then launches it. With a dialog box shown by the loader to tell what is happening, upgrades are automatic and no user interaction is required.