Workspaces, Version Control, Deployments

[CoastalLabVIEWER]

At the moment our development environment lives in C:\TopLevel with an assortment of directories below this containing ~400 VIs and ~150 .seq files.  We haven't used the LabVIEW project files or TestStand project files and workspaces for anything.  Most .seq files that refer to other .seq files and VIs that refer to other VIs do so with static paths.  For version control we use Team Foundation Server and have generally been limited to a single main branch of development.  Our team has varied from 3-6 people and for a lot of the past year or so it was really only 1-2 developers and the rest were users so being restricted to one branch on the version control side and a single fixed C:\TopLevel directory hasn't been too much of a nuisance.  However, the work is now expanding with more people developing and more features being needed and the need to be able to try out new features in a "walled off" way and merge to other branches (basically traditional software development) is apparent.

When I first tried to branch from the main branch and work in a different directory than C:\TopLevel (eg C:\NewFeatures) all the static paths reared their ugly heads.  I also had similar annoyances trying to test the deployment features.  I don't have a ton of experience with TestStand workspaces and TS and LV project files, but from what little bit I've read this is likely the direction I need to go in to make software development work better.  I was looking for some advice on a quick way if there is one to get from A to B without having to make everything on the LV side project file based (and thus have to go into tons of VIs and .seq files and re-link) and without having to do similar in TS to get me to the point where I can branch from my main branch and be able to A) work out of a different directory and not have path/linking issues and B) be able to do deployments.

[dug9000]

Do you mean you are using absolute paths to specify your code modules in your .seq files? If so I recommend you use paths that are relative either to the sequence file referencing the code module or to a non-recursive search directory which contains all of your code modules. I do NOT recommend using recursive search directories because it can lead to false matches if you have multiple code modules with the same name.

Relative paths can be more than just the file name, for example:

somedir_a\somdir_b\mycode.vi

is a valid relative path. The path could either be relative to the sequence file containing the path or a custom search directory. This will better allow you to move things around without breaking your sequences.

-Doug