My lvlib paths/URLs are obviously absolute

[flintstone]

NI has been contacted, let's see.

[Aristos Queue]

Flintstone: This does not sound like there is any bug to fix. Your description sounds like you resaved your files such that the two files were on different drives, so LV saved the absolute path between them when you asked it to save. That's correct behavior, not a bug in any way.

 

> Is it possible that other VIs inside an lvlib get affected LV changes a path from relative to absolute?

 

This question is missing some key words for me to be sure I'm parsing it correctly, but I believe the answer is "of course". If any source file is in memory and other source files reference it, when those other source files save, they will save with the path to that referenced file. If you loaded it from another machine, all the referencing files will be updated and will have new paths when saved.

 

This appears to be a case of LabVIEW doing exactly what you asked it to do. What bug are you expecting National Instruments to fix?

[jives]

I think what happened was roughly as follows (maybe flintstone could correct me if I'm wrong)

1. Save files on the local drive C: in SVN working copy.
2. Commit to SVN.
3. Delete working copy on local drive C: and checkout on network drive R:
4. Open project 1 (using X.lvlib) from R: and work without any issues for any of the relative paths in X.lvlib
5. Open project 2 (using X.lvlib) from R: while project 1 is loaded into memory and get the "loaded VIs from different path" popup for X.lvlib:A.vi and X.lvlib:B.vi
6. Save and commit project 2.
7. Update working copy containing project 2 on another machine. Path for X.lvlib:A.vi is now absolute, while path for X.lvlib:B.vi is relative (both files are actually located under "R:MyLibA.vi" and "R:MyLibB.vi")
   

The popup from step 5 seems a bit suspicious (X.vilib should already be loaded into memory completely), but maybe someone had the VIs in a different location before. However, step 7 is very unexpected, because I'd expect all VIs in X.lvlib to be saved with either relative or abolute paths (or at least theVIs indicated by the popup).

Edited April 19, 2013 by jives

[Aristos Queue]

Please bear with me... I'm going to ask some questions to try to understand what's going on a bit more. This is an area of LabVIEW that has a pretty long established pattern of behavior that generally makes sense to users. If it sounds like I am looking for you the user to be at fault instead of looking for LabVIEW -- and by extension, us, its developers -- it is because the subsystem that you are having issues with is one that has a pretty long history of working. (Note: I am talking about the choice LV makes about which path to save, NOT the control LV gives you for fixing those paths... lots of us will acknowledge that fixing issues like this could use some improvement.) If it turns out that LV does have a bug, we'll definitely acknowledge it, but I'm not expecting that. I write this preamble because sometimes customers have been upset with me when I go looking for problems in their behavior and/or expectations rather than just immediately accepting that LV must be at fault.

 

Your seven steps, restated, with questions along the way:

1. Save all three files onto the C: drive:
   1. X.lvlib
   2. X.lvlib:A.vi
   3. X.lvlib:B.vi
      

[*]Commit all three files to SVN. Can you check your SVN history and verify that
  1. All three files were really checked into the SVN at that time and
  2. That X.lvlib contained relative paths at that time.
This will help to confirm that we start this story from a known point. My first thought is that you, at this point, had both C: and R: versions and maybe, just maybe, you already had cross-linking at this point, where a VI on the C: drive was linked against a library on the R: drive or vice-versa. [*]Delete the working copy from C: drive and check out on network drive R:
So you had mapped the SVN repository in two places originally... that's what made me think there might be a problem at step 2. [*]Open project 1 and work without issues.
A library file does not load all of its VIs into memory. If you had cross-linking within X.lvlib already at this point, there might not be any dialog depending upon the exact VIs your project caused to load into memory. [*]Open project 2 and get the warning dialog
So we know that something was *already* saved pointing at the wrong location such that when we loaded project 2, it gave you the warning dialog that it was redirecting to the R: copy. [*]Save and commit project 2
Are you committing just the .lvproj file or are you committing all the changes made while editing project 2? Did you actually commit all the files that triggered the dialog warning? I'm still assuming that you were *already* cross-linked back in step 2. My theory is that the dialog was a warning that LV was *correcting* the paths, but us autocorrecting the paths does not check a VI out from the repository. You would have to choose to check it out and then check it in fixed up. I doubt that you did this. [*]Update project 2 on another machine
If you go back to step 2 and open on another machine, my current theory is that you would have had trouble back then.

My theory may not hold water -- it's easy to check by looking at the SVN history. But it is the thing that feels the most right. That's *especially* true in light of step #6, where the dialog came up saying that files were found at a new path. Since the only path they could be found at is the local R: path, that means they were already wrong by that point.

 

Can you check this and see what you find?

[jives]

Thanks for the extensive reply!

 

Ad 2 and 3:

I'll check as soon as I'm back at work, but it is highly unlikely that we had crosslinking between C: and R:, because R: did not exist before step 3 in my list. We just switched because we were forced to by our IT handling the VMs.

 

Ad 3:

It may be that the working copy was located in different locations on different machines, but I am quite certain that it never left the C: drive

 

Ad 5:

Definitely true! At least one VI was loaded from another location, and I am sure the first one was "find_buffer.vi" of the NI-Motion module, which we have in our working copy and which is also included in <instrlib>. I can try to reconstruct which VIs were affected here.

 

Ad 6:

I committed all files that where changed in the working copy, including the files that triggered the warning and the lvlib they belong to. This is also where we ended up with absolute paths in the lvlib. I am not sure what you mean by

 

[...] but us autocorrecting the paths does not check a VI out from the repository. You would have to choose to check it out and then check it in fixed up.

 

I checked the files out manually using TortoiseSVN in step 3, and committed them back in step 6 after LV had updated them.

 

Just to make sure that my memory isn't failing me here I'll try and check all of the above once I'm back at work though.

[Aristos Queue]

 I am not sure what you mean by

 

What I meant by that is this:

 

A VI stores the paths to its subVIs (or to its library or any other dependency).

When the VI loads into memory, it loads its dependencies if those dependencies are not already in memory.

If they are in memory, we check to see if they were loaded from the same path. If they were NOT loaded from the same path, we update the copy of the VI in memory to point to the location of the dependency in memory and give you the load warning. But although the VI in memory has been modified at that point, we do not check it out from source code control (the way we would if you had started editing it) nor do we mark it as having unsaved changes. If you proactively save the VI or start making other edits and then save it, then the VI will be saved with the new path.

 

Given all of that, if the reason we had posted the warning dialog was because we were *fixing* the paths back to what you expect, that fix would not be saved to disk unless you did something to cause the VI to be saved.

[jives]

Got it now We don't use the LV VCS integration feature, so the checkout/checkin procedure is done by us manually via command line/TortoiseSVN. Before we check-in, we use the "Save all" feature in the Project Explorer (at which point SVN recogizes that the VIs have been changed) and only then commit the whole working copy and select all affected VIs.

 

Unfortunately I didn't have the chance to check our SVN changes yet, but once I've done this I'll report back here!

[flintstone]

It seems this was never really resolved (or nothing more happened?) but since I made some general statements in this thread I want to give a final feedback: Of course  it wasn't quite possible to switch the project away from LV but I went the other way and left the company and thus the LV world by end of June to work in a C/Matlab/[whatever gets the job done] environment. After nearly three months in my new company I totally stand by my statements regarding reliability of the development environment and long-term support. Both these issues are very big topics in my new company, they don't come easily but we can manage them. It feels like being back in the driver seat again.

 

So thanks to everybody who helped me in this forum, I wish you all the best and hope that I will never again need support on lavag.

 

Cheers,

flintstone

[todd]

Thanks for sharing. Congratulations on 50 posts!