False linking of VI(s) to .svn folder

[sam]

Hi,

I have a concern regarding SVN. I have been using SVN since/before 2004. Lately I am having a lot of VIs that are incorrectly linked to the .SVN folder; I am blaming the project explorer. I am having a lot of frustration with this, and hate the fact that I need to relink more and more VIs to the actual file from the temporary SVN file. If there isn't a solution found for this incorrect linking I will abandon my favorite SCC.

Has anyone else ran into this? What do you do to avoid false linking?

As always I appreciate your kind help.

[Aristos Queue]

QUOTE (sam @ Dec 31 2008, 09:43 AM)

Has anyone else ran into this?

I use Perforce which keeps the repository on a separate machine, so there's no chance of local VIs crosslinking to the repository files. Having said that...

QUOTE

What do you do to avoid false linking?

Yes, I have encountered this problem, but more rarely in recent versions of LabVIEW. I'm surprised to hear you blame the project explorer -- that has gone a long long way toward preventing these problems, particularly LV version 8.5. That version added

• cross-link detection before the VIs load into memory (if a caller VI in your project links to a subVI not in your project, the project checks to see if another subVI of the same name is already in the project, which indicates that the caller VI has linked to the wrong item).
  
• the File view of the project (shortcut key ctrl+E when on the Project Window) that lets you quickly see if any VIs are linked that are from unexpected directories.
  
• protection for VI renaming... when you rename a VI, LV updates all the caller VIs in the project, even those you haven't loaded into memory, so you have fewer cases of loading a caller VI and its subVI being gone, triggering a search for the subVI.
  
• and some rather powerful untangling tools. There are several problems with the untangling tools when libraries (.lvlib, .lvclass, .xctl and .lvsc) are involved, but if you're working purely with VIs, these tools are a major aid.
  

Cross links of the type you describe almost always come from a caller VI missing a subVI and then LV searching for the missing subVI and finding it. Do you frequently rename VIs on disk instead of renaming them inside LabVIEW? Are you using libraries, moving a VI inside a library (which changes its fully qualified name) and then not saving the caller VIs? Can you move the svn directory to a location where LV won't automatically search it when looking for missing VIs?

[LAVA 1.0 Content]

I would try to get a clean repository, the easiest is to commit everything to the repository, remove the .svn folder.

Then set SVN to use _svn folders instead of .svn folders. ( I know this is possible with TortoiseSVN).

Now if you open up a VI with false links, LabVIEW will start searching (but will ignore the _svn folders) and you can relink.

Ton

[Aristos Queue]

QUOTE (Ton @ Dec 31 2008, 11:21 AM)

Now if you open up a VI with false links, LabVIEW will start searching (but will ignore the _svn folders) and you can relink.

What causes LabVIEW to ignore _svn directories? Is that something built into LabVIEW?

[Jim Kring]

QUOTE (sam @ Dec 31 2008, 07:43 AM)

Hi,

I have a concern regarding SVN. I have been using SVN since/before 2004. Lately I am having a lot of VIs that are incorrectly linked to the .SVN folder; I am blaming the project explorer. I am having a lot of frustration with this, and hate the fact that I need to relink more and more VIs to the actual file from the temporary SVN file. If there isn't a solution found for this incorrect linking I will abandon my favorite SCC.

Has anyone else ran into this? What do you do to avoid false linking?

As always I appreciate your kind help.

Which LabVIEW version are you using? Are you using auto-populating folders or did you add the .svn folder contents to your project? In older versions of LabVIEW, auto-populating folders didn't ignore hidden folders (.svn folders are typically "hidden"). That's the only way that I know of that would cause you to get the cached repository VIs (located beneath .svn) in your project. These cached repository VIs have different file names, so LabVIEW should never relink to these unless you tell LabVIEW to do so, or accidentally use one of them in your project.

Or, did you do a mass compile (Tools>>Advanced>>Mass Compile) operation? This can cause problems, because LabVIEW will attempt to mass compile the cached repository VIs. This may have been fixed, but I don't think so -- I avoid the Mass Compile tool.

QUOTE (Ton @ Dec 31 2008, 09:21 AM)

I would try to get a clean repository, the easiest is to commit everything to the repository,

remove the .svn folder.

Then set SVN to use _svn folders instead of .svn folders. ( I know this is possible with TortoiseSVN).

Now if you open up a VI with false links, LabVIEW will start searching (but will ignore the _svn folders) and you can relink.

Ton

QUOTE (Aristos Queue @ Dec 31 2008, 10:00 AM)

What causes LabVIEW to ignore _svn directories? Is that something built into LabVIEW?

There are a variety of situations where LabVIEW ignores any folder/file that begins with an underscore. For example:

• populating the palettes (synchronize with directory)
  
• populating the Tools, File, and Help menus with menu-launch VIs
  

However, I think Ton's assertion might not be true -- I don't believe that auto-populating folders or the search dialog ignore underscore-prefixed files/folders.

[sam]

I am using LabVIEW 8.6, but I have seen it as well in LabVIEW 8.5.

Jim, I think you are correct regarding auto-pop. feature leading to cross-linking. I will stop using auto-pop and see if cross-linking is reduced or gone.

Also I don't think using "_svn" instead of ".svn" will fix this cross-linking. If I remember "_svn" was a hack to fix a bug with ASP.NET 1.0. I think ".svn" was a reserved word in ASP.NET. Also this hack no longer is necessarily for current ASP.NET

Aristos, I always rename using LabVIEW file save as. I try to never rename in Explorer, exactly for fear of cross-linking.

[jdunham]

Just another data point, I have been using SVN since about the same time (2004) and have not experienced this problem at all.

QUOTE (Ton @ Dec 31 2008, 09:21 AM)

I would try to get a clean repository, the easiest is to commit everything to the repository, http://thinkinging.com/2008/09/23/removing-svn-folders-from-a-working-copy-with-tortoisesvn/' rel='nofollow' target="_blank">remove the .svn folder.

Then set SVN to use _svn folders instead of .svn folders. ( I know this is possible with TortoiseSVN).

Now if you open up a VI with false links, LabVIEW will start searching (but will ignore the _svn folders) and you can relink.

Exporting is a good idea, but my recommendation would be to

1. commit your svn working copy, if it's not too hopelessly broken
   
2. svn-export your files to another location on disk so that there is no SVN at all
   
3. Load up the exported copy and fix all the linking. Save all the changed VIs, of course
   
4. *carefully* copy your exported hierarchy back onto the original files, replacing everything. This should be a single drag-and-drop with the Windows Explorer
   
5. commit your fixed working copy back to the repository
   

[sam]

I am attaching this Picture to show VIs linked incorrectly. Notice how ".svn" is a parent folder for the VIs

[Jim Kring]

QUOTE (sam @ Dec 31 2008, 10:51 AM)

I am attaching this Picture to show VIs linked incorrectly. Notice how ".svn" is a parent folder for the VIs

That's odd, because all the files below the ".svn\text-base" folders should be suffixed as "*.svn-base". In your screenshot, they are missing the ".svn-base" suffix.

[jdunham]

QUOTE (Jim Kring @ Dec 31 2008, 11:20 AM)

That's odd, because all the files below the ".svn\text-base" folders should be suffixed as "*.svn-base". In your screenshot, they are missing the ".svn-base" suffix.

Given this, I would amend my recommendation so that you export first, and then revert your working copy or check out a fresh one, and then copy the properly linked version back over your working copy.

[LAVA 1.0 Content]

I never had this issue (thanks to the good cross-linking dialog in LabVIEW 8.2+).

So I never tried _svn, but use_svn_directories wiki entrance made me thinking.

If I search for _svn it looks like I started the rumours

Ton

[sam]

QUOTE (Jim Kring @ Dec 31 2008, 02:20 PM)

That's odd, because all the files below the ".svn\text-base" folders should be suffixed as "*.svn-base". In your screenshot, they are missing the ".svn-base" suffix.

I bet internally the Dialog or Linking Algorithm is dropping the ending ( .svn-base). maybe searching for .vi and assuming the [ Path.Name.vi ] as the vi name.

To clarify my problem is not how to fix this error, but how to prevent it from happening, I can fix the errors in any number of methods, some being the ones mentioned.

The interesting point here is that I get this error on most of my project, but some of you here never seen it. therefore pointing to my style of programming ( Folder Structure maybe) :-) That inevitability causes Linking Problems. Like stated earlier I use Auto-Pop heavily, and Auto-pop adds the ".svn" folder to the project.

It would be very nice to have an option setting for LabVIEW to ignore some file types and names.

[LAVA 1.0 Content]

QUOTE (sam @ Dec 31 2008, 09:36 PM)

Like stated earlier I use Auto-Pop heavily, and Auto-pop adds the ".svn" folder to the project.

It would be very nice to have an option setting for LabVIEW to ignore some file types and names.

There are reasons auto-populating wasn't in the first releases of 8.x

:ninja: .

The only reason I can see someone is using auto-populating is when you create VIs outside of the LabVIEW project.

Why?

Maybe you should write your own Auto-Pop routine?

Ton

[Aristos Queue]

QUOTE (Ton @ Dec 31 2008, 03:40 PM)

There are reasons auto-populating wasn't in the first releases of 8.x

There are reasons why I opposed its introduction into current LV versions and would have no qualms if it went away in future versions. Unfortunately, I am in the minority, both among developers and users. I loathe that "feature."

[Yair]

QUOTE (Aristos Queue @ Jan 2 2009, 05:53 AM)

I loathe that "feature."

Can you expand on that? I only really started using 8.x recently and would prefer avoiding it if there are good reasons.

[Aristos Queue]

QUOTE (Yair @ Jan 2 2009, 03:07 AM)

Can you expand on that? I only really started using 8.x recently and would prefer avoiding it if there are good reasons.

I've argued it elsewhere in these forums, but the short story is that the feature contradicts the basic principles that we designed into the project and it causes logical contradictions to arise when using libraries (all types of libraries: .lvlib, .lvclass, .xctl and .lvsc). The project was designed to help you separate the physical layout on disk from the virtual layout in your project. That was a feature, and it is a good feature. The autopopulating folders unifies those two again, which once again means there is a lot of churn among caller VIs when a subVI moves to a different folder, and it means that source code control revision history is harder to track whenever VIs go through moves on disk. It moves us in the wrong direction: toward more disk integration instead of less. Libraries in the project show ownership tree -- but if the library is inside an autopopulating folder, you get all sorts of stupid situations when trying to use libraries, and we in LV had to invent all sorts of arbitrary rules for handling cases... for example, a library is in an autopopulate folder, but one of the members of that library is not in the same directory (this is common for sublibraries). The library is listed under the autopopulate folder; and under that library, the owned item is also listed, even though it isn't in that directory.

I know why a lot of folks like the autopopulate folders. I get the "ease of use" arguments. But in my opinion they're just like global VIs: easy to learn, quick to implement and a complete disaster for long term code maintenance.

[Jim Kring]

QUOTE (Yair @ Jan 2 2009, 01:07 AM)

Can you expand on that? I only really started using 8.x recently and would prefer avoiding it if there are good reasons.

I believe that the only good reason for using auto-populating folders is due to a limitation in the build spec scheme that requires any file that will be included in the zip/exe/installer to exist in the project (ideally, we should be able to create installers from items on disk using wildcards and optional recursion, rather than just items in the project). Hence, if you want to include all files in your "images" folder in your installer, without updating your project or build specifications every time you add a new image to your images folder, you can make your images folder auto-populating and then in your build specs add this auto-populating folder to the installer.

[Aristos Queue]

QUOTE (Jim Kring @ Jan 2 2009, 02:31 PM)

(ideally, we should be able to create installers from items on disk using wildcards and optional recursion, rather than just items in the project)

Ideally you what?! Weren't folks just complaining about cross-linking? Yes. And yet now you want to add it as a feature for build specs. *sigh*

[Jim Kring]

QUOTE (Aristos Queue @ Jan 2 2009, 03:05 PM)

Ideally you what?! Weren't folks just complaining about cross-linking? Yes. And yet now you want to add it as a feature for build specs. *sigh*

Yes.

[crelf]

QUOTE (Aristos Queue @ Jan 1 2009, 10:53 PM)

There are reasons why I opposed its introduction into current LV versions and would have no qualms if it went away in future versions. Unfortunately, I am in the minority, both among developers and users. I loathe that "feature."

I, too, would have no problems if it went away in future versions. I was disappointed when that feature was released, as, IMHO, it circumvents the whole reason to have the project in the first place: to have virtual links to everything required by a project. It takes us back to the pre-project days before LabVIEW 8. The only reason I can think of using it is if I had a folder of purely dynamic VIs that is added to, deleted from, edited in some way outside the contaxt of the project. That said, I would still want to update my project - because that's the place that everything should be linked from - otherwise you're just trying to hide things from other developers.

[Aristos Queue]

QUOTE (Jim Kring @ Jan 2 2009, 06:34 PM)

Yes.

Why? Wouldn't that make the situation described here worse? You would conceivably have a project that works perfectly well in development, then you build an EXE and suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards. What can you pick up in a build spec that you cannot pick up in the project itself?

[Yair]

OK, I'll have to look that discussion up. I figured there probably was, but the LAVA search generally isn't great and I was feeling lazy.

I only used the 8.x builder once, but I've also felt the need at least to be able to browse to select files to be added to the build. For instance, why would I want to have the icon for my application in the project? I'm only interested in it when I go to build the app. I understand the logic behind this (it's part of the project, it allows to show missing items, etc.), but in this example it simply disrupts the workflow (I go to build the app. Oh, I need an icon. So, a minute later I created one and now I need to add it. Now, where's the browse button?). It might be easier if we had a browse button in the relevant sections of the builder which would automatically add the selected files to the project.

[Aristos Queue]

QUOTE (Yair @ Jan 3 2009, 10:17 AM)

I only used the 8.x builder once, but I've also felt the need at least to be able to browse to select files to be added to the build. For instance, why would I want to have the icon for my application in the project? I'm only interested in it when I go to build the app. I understand the logic behind this (it's part of the project, it allows to show missing items, etc.), but in this example it simply disrupts the workflow (I go to build the app. Oh, I need an icon. So, a minute later I created one and now I need to add it. Now, where's the browse button?). It might be easier if we had a browse button in the relevant sections of the builder which would automatically add the selected files to the project.

That makes sense for the icon, but not for the VIs, in my opinion. The icon doesn't affect the runtime behavior of the VIs. My argument against the build spec accessing VIs not listed in the project is that it changes the behavior of the VIs from what you would have tested in the development environment.

[Jim Kring]

QUOTE (Aristos Queue @ Jan 3 2009, 06:40 AM)

Why? Wouldn't that make the situation described here worse? You would conceivably have a project that works perfectly well in development, then you build an EXE and suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards. What can you pick up in a build spec that you cannot pick up in the project itself?

> suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards

Only if one used improper settings that allowed the .svn folder contents to be included -- the .svn folder contents should be exclude-able in the build spec scheme.

The general pain that I'm describing is caused by the fact that you can only "build" things (exe, zip, installer) from sources that exist in your project. Building a software product typically involves several cascaded build steps (in most situations this is an EXE, followed by an Installer, followed by a ZIP file). The project environment bonks when it can't find project items. And inputs to a build step generally don't exist until a prior build step completes -- this is why, IMO, it doesn't make much sense to require that items exist in the project in order to build them (since the auto-populating folder scheme is so "dumb" in how it auto-populates). Plus, projects (and auto-updating folders) don't update/refresh between build steps. Maybe you could use multiple projects, but this is also a bit of a kludge and means that you can't build in a single step -- it also means that you can't open a downstream project until an upstream project is built. Bottom line: using the project environment to build any non-trivial software product is a painful endeavor -- you should http://thinkinging.com/2008/05/27/a-dogfooding-challenge-to-ni-use-your-application-builder/' rel='nofollow' target="_blank">try it sometime

[Yair]

Sorry, you can actually browse for an icon from the icon dialog and it adds it to the project. What I was thinking of was that the icon had to be in the project and so if I removed it I did not have an icon, but let's accept that this is reasonable behavior.

One thing I did see is that you expand the dependencies item in the builder, so if you want to modify the VI properties when building, you have to explicitly include it in the project. Again, I haven't worked with the project enough to be able to formulate a worthwhile opinion, so there might be good reasons for this.