07-12-2012 05:03 AM
Hello,
We have LabVIEW integrated with our source control system, using SCC.
When we make a change to the project file, e.g. add a VI, this checks the project file out and applies the change. On occasion we get the message "The file <project file> has been changed on disk by an external action. You will need to reload then poject to reflect this change"; .e.g some has worked locally for a while and has gone to get the last version of the project from source control.
To perform this reload we are having to exit LabVIEW and re-start it, otherwise we sometime get a locally cached version.
Is there a better way of forcing it to reload, preferably automatically?
Thanks, for the help
Jon.
07-13-2012 11:32 AM
Hi Jon,
Would you be able to tell me which versions of LabVIEW & your source code control software you are working with please?
Also, do you know how you have the source code control software configured in LabVIEW?
Many thanks,
Ali Bailey
National Instruments
07-16-2012 03:05 AM
Hi,
LabVIEW 2011 SP 1
Boarland StarTeam 2008 Release 2, which integrates via SCC
If I click Tool - Options - Source Control the settings are as follows:
I can tell you more if you want to know something more specific?
Our folders in the LabVIEW project are not auto populating, but having raised a support call a while ago I think we came to the conclusion that that was of little consequence either way.
07-16-2012
09:26 AM
- last edited on
05-19-2025
04:07 PM
by
Content Cleaner
Hi Jon,
I have been doing some more digging and I have found that there can be a few causes. One of the most common is that Sub VIs are being changed, causing any calling VIs to need updating because the compiled binary has been modified. To accomodate for this, there is a property of a VI that allow you to separate the binary from the source file so that SCC doesn't worry about changes to the binary. Here is a link to the LabVIEW Help file that describes that function in more detail (Separating Compiled Code from VIs). If it turns out that this is the issue and you have a lot of VIs to change this for then I have found a post from a member of the community that seems to help in outo setting that property (Separate Compiled Code for VIs and other files).
Hopefully that will be the cause and those links help.
Let me know how things progress.
Best regards,
Ali Bailey
National Instruments
07-17-2012 04:55 AM
Hi
Thanks for the info, I'll have a read. It looks interesting.
Specifically we have a problem with the project file.
Assume there are two team mambers A and B, both working with the same held in source control.
If person A adds some VIs to their project, but doesn't check out the project from source control (e.g. they want to work locally for a while until they've built their VIs), they will get a writable local copy of the project file.
Person B checks out the project, adds VI, checks in the VI and the project.
If person A then goes to check out the project they get the lock on the project but the project file, and hence what they see in project explorer; is their cached local copy. Only by closing LabVIEW without saving changes to the project file and then reopening LabVIEW and then the project can person A get back to the copy from source control.
Is there an option in LabVIEW to allow the project file to be forcably reloaded, without having to exit?
Will disconnecting the VIs and the compiled code help resolve this issue?
Thanks for the help,
Jon.
07-17-2012 08:40 AM
Hi Jon,
I don't anticipate that my suggestion will solve your issue I am afraid if it is changes with the project file specifically as it is just an XML file behind the scenes.
When you are getting the lock on the project it sounds like person A has their local copy still open. If this is the case then am I correct in thinking that the local copy and SCC copy have the same name?
Also, does person A have to just close the project and return to the "Getting Started" screen or do they have to close that too?
07-17-2012 08:49 AM
Hi,
Yes person A has their copy still open. Not sure how you get the latest version of the project file without having the project open. We could use the source control client rather than the LabVIEW integration, but that would defeat the point really.
You also have to close the "Gettting Started" screen as well; i.e come right out of LabVIEW.
Been playing around a bit. We get the same problem when we just do a "Get latest version" on the project file.
In contrast with a VI, you get a popup box that asks you if you would like to revert to the disk version (which has just been extracted from source control) and loose you're changes, that would be OK as a sloution for the projectbut we never see that popup.
Jon.
07-17-2012 09:29 AM
It happened not only with project file, but also with libraries (and classes, I guess).
When someone has added some new items into the library, then other person should reload whole project.
Refere to this topic - Re: Get latest version: New vi's do not appear
07-17-2012 09:43 AM
Hi,
(Front the last post in the first page)
"Regarding Get Latest, when I perform that action, I do get a prompt that states that the
file has been changed on disk and that you need to manually reload the project. The project
is not automatically reloaded due to issues involving running VIs, connected targets, etc.
and what the behavior would be of automatically shutting all that down. We figured the
customer would be know how to clean up and then manually reload the project."
Yep, that's the problem.
Is there a way of not having to exit LabVIEW in order to reload the project?
Is there an option somewhere, given that that thread was 4 years ago, that allows the project to be reloaded?
07-17-2012 10:37 AM
@jonnnnnnn wrote:In contrast with a VI, you get a popup box that asks you if you would like to revert to the disk version (which has just been extracted from source control) and loose you're changes, that would be OK as a sloution for the projectbut we never see that popup.
Jon.
Project present a larger scoping problem with trying to revert them. You could have many VI open from the project and those VI could be edited with unsaved changes or running. You could be connected to a target or performing other actions controlled by the project. Rather than causing loss of work by automatically attempting to reopen the project, that exercise if left to the user. There could be issue with trying to force shutdown running VIs and leaving resources uncleaned (if using hardware) and so forth. With VIs, the scope is much more limited and so we present the option to revert the file for you.
The recommended process for dealing with this situation is to always get the latest version of the project before starting any development to make sure that it is up to date. You can then take advantage of a menu option on the project file itself - "Get Latest Version of All Files". This option will list all the files in the project including any new ones that you don't currently have and get the latest version of the files.