LabVIEW
File permission issues when sharing project
I don't have any advice for the issue itself, but maybe a little for the troubleshooting process...
It would help if anyone who is experiencing this issue stated their current versions of LabVIEW and Windows, so others can attempt to replicate. This does seem like it would be a hard one to replicate however. The OP was using Windows 7 when they originally posted. Couldn't attempt to replicate that if I wanted to unfortunately, all Win10 here.
A zipped up simple project that exhibits the issue might help, but then the folder that contains it would have to have the proper permissions applied and the dev attempting to replicate would need multiple accounts belonging to a local group.
The versions are by far the main thing though. Without those we have no idea where to even start.
@Bob_Schor wrote:
@itronChiraldude wrote:
My typical routine is to commit changes at the end of each workday. There should be no need to delete and copy back from repository every day. Only one system so only one developer can access at a time (typically via remote desktop). Also, project is huge and takes > 5min to copy across the network.
Regarding VCS and the "typical" process -- it does not involve a "copy back from repository every day". There are three basic operations (I'm going to use the terminology from Subversion, as this is what I use):
- Checkout -- you do this once (for a new PC) to download the (latest) version of the Project. This does involve a full copy of the entire Project, so it might take 5 minutes, but you do this once.
- Commit -- ideally, you do a Commit (with notes that say what changes were made, so you can look back and find "where the bug was introduced") on a regular basis, certainly when you come to a "resting place". Commit intervals range from every few hours to daily to weekly to rarely (the latter group might get less benefit from Version Control).
- Update -- if you Commit in the evening before going home, you should Update in the morning to upload any changes that were saved to the Repository since your last Commit.
Note that the "daily routines", Commit and Update, only transfer files that have been altered, which in a 1000 VI project, with regular use of CVS, should amount to a few dozen changes that should take 10-30 seconds.
Right now, I'm largely working remotely, so everything is on my laptop. Two years ago, I had a desktop in my office where I did most of my work, and on some evenings and weekends, I would do a little on my personal laptop. By committing before leaving my office, and updating before starting work from home (a process that did only take around 10 seconds, typically), I didn't have to "guess" that I had the latest version, nor worry about carrying USB sticks around with who-knows-what version on it (or worse, "My Routine v2.3.1a"). Of course, I had to remember to Commit before I went to bed, so what I did would be available when I got in to work and updated. [Note -- if nothing has been changed, an Update "does nothing" and is very fast).
Bob Schor
I am going to endorse this post. The reason why versioning software is around is not to keep track of revisions between multiple people, although it certainly helps. The main reason for the existence of versioning software is to give you a time machine so if something goes drastically wrong with your software, you can find a revision where the bug did not exist, and then decide what to do from there, whether it be to actually go back to that version, or just compare the two revisions to see what might have cause the issue. I use SVN (with the Tortoise front end) at home for all my projects, even though I am the only one developing.
OP, you would be well advised to use some kind of versioning software before it's too late. Buckling your safety belt after a car accident is useless.
@maherhome wrote:
I'm the original poster and it's fun seeing this thread come back to life after 9 or so years!
Looks like spontaneous permission change is still an issue - I haven't done team LV development in years (I'm primarily a traditional software engineer - Java, C++, Python....). Hopefully it can be nailed down soon.
Someone suggested making all Labview developers "Local Administrators". Yes, you can still maintain good security but granting "elevated privileges" to users is not done lightly in many organizations; we have to pass several courses to get it.
Lot's of talk about VCSs. Ideally each LV developer would have a sandbox and use a VCS to sync. However, last time I checked doing diffs and merges of a LV file is far from straightforward.
Cheers,
Steve
It's actually pretty straightforward, there's just a lot of files to merge instead of just a couple of text files. There's a LabVIEW option to select to make it not so cumbersome, but really the biggest issue is that LabVIEW is a lot of functions, each having its own file, instead of lots of functions residing in only a few text files.
@maherhome wrote:
Back in the day (9 years ago!) I played with LVCompare/LVMerge to try merging. It was difficult (for me) with anything but trivial differences. This 2020 NI video seems to agree (27:30). I completely understand as it's a very difficult problem!
@billko wrote:
@maherhome wrote:
I'm the original poster and it's fun seeing this thread come back to life after 9 or so years!
Looks like spontaneous permission change is still an issue - I haven't done team LV development in years (I'm primarily a traditional software engineer - Java, C++, Python....). Hopefully it can be nailed down soon.
Someone suggested making all Labview developers "Local Administrators". Yes, you can still maintain good security but granting "elevated privileges" to users is not done lightly in many organizations; we have to pass several courses to get it.
Lot's of talk about VCSs. Ideally each LV developer would have a sandbox and use a VCS to sync. However, last time I checked doing diffs and merges of a LV file is far from straightforward.
Cheers,
Steve
It's actually pretty straightforward, there's just a lot of files to merge instead of just a couple of text files. There's a LabVIEW option to select to make it not so cumbersome, but really the biggest issue is that LabVIEW is a lot of functions, each having its own file, instead of lots of functions residing in only a few text files.
What is s the LabVIEW "option" you mentioned?
Thanks,
Steve
df
Oh, it's the option to separate compiled code from its source. What this does is drastically reduce the ways a VI can be flagged as "recompiled", so your versioning software doesn't have to include it in a commit. Enabling the option in LabVIEW ensures that all future projects and VIs will have behave in this manner; for pre-option projects and VIs not in a project, they will have to have that option set manually. (Although if the option needed to be set in a project, there's a simple way to turn on the option for all VIs belonging to the project.)
Versioning software should treat VIs as binary files and shouldn't try to merge them; by default, it will treat your LabVIEW library and project files as the text files they are, and will sometimes outsmart itself and do an "intelligent merge" and render the file unusable. Best to tell the versioning software that these are binary files so at least any conflicts will still result in a workable file.
