Labview has direct paths to dependencies, why does it need me to select the file?

[TolkienWASP]

EDIT: It appears the 'Expected Path' was in fact slightly different than the actual path... Why LabView seems to have assumed a folder at the root level directory that doesn't in fact exist, I have no idea. But problem solved! 

------------------------------------

Hey!

I have created a set of folders to act as a repository to track changes and releases of my Labview Project. It is a fairly complex set of VIs, however all of them are rooted in a single directory. I have developed a set of scripts to manage this 'repository', by copying and moving the root directory for each of these software releases. 

What I'm not clear on, is why after a copy has been complete, the new VI demands manual selection various sub-vi's during its first start up -- even though the name it is searching for references a direct path to the VI being searched for. It does appear to attempt to search for the file, and seems that it can't find it even though it has the direct reference to it....

Why this is an issue, is that in the event a given release of the project is buggy -- the VI operator can run a roll back script to move to a prior release, and effortlessly get back online with little to no downtime. Although selecting the files is easy enough, it is still another detail to which the operators would need training on. 

Any thoughts as to how labview can select these VIs without manual selection?

Thanks!

[tst]

LV has three ways of storing file positions:

1. Logical - these are items in folders like vi.lib.
2. Absolute - these are items which are on different volumes (drives).
3. Relative - anything that doesn't match the first two. This is how most paths are stored.

Most likely, the paths are relative and when you move the files you don't maintain that relation, so when LV opens the file next time, it doesn't find the file where it expects it to be.

As a more general point, my suggestion would be to use a proper source code control system for managing versioning and synchronization. You can read up a lot on what people recommend. Personally, I use SVN, which is quite common both among LV users and in the general programming community.

[Bob_Schor]

Wait a minute, are you trying to re-invent Version Control, but do it within LabVIEW?  Version Control is a Very Good Thing for the LabVIEW Developer (there have been numerous talks at NI Week on "Good Practices" and VCS is almost always mentioned and praised), with many of us using Tortoise SVN (and there are even Tools for this in the LabVIEW Tools Network).  Why try to re-invent this wheel, which is pretty complex if you want to do it right?

You mention LabVIEW Project.  Project maintains (in the Project file) its own directory of where the files used in the Project are located -- in particular, they do not need to be in the Folder tree that contains the Project File, but can even be on another disk.  If you Copy/Rename from within Project, you keep these associations, but if you start moving files around in Windows Explorer, you "break" the connections and things get messed up.  Fortunately, when you restart Project, it alerts you that you've broken its internal links and helps you repair them.

Note that the same thing happens when using VCS -- in SVN, for example, moving a File from one folder to another will register as "Delete File from Folder A" and "Add File to Folder B" when you go to do the Commit.

Bob Schor