Thanks for you comments, the main reason for the network usage is more for
common add-ons etc.
However we do intend to edit groups of VI's together.
The problem you describe below is true of any language not just Labview and
one that
I understand well, having been responsible for configuration control with
Clearcase on
a number of C, C++, Tcl projects with quite large teams.
I am intending to use the Labview provided Source control tool to overcome
these particular problems.
I know I do not yet know the particular idiosyncrasies of Labview or the
tool set but it is normally just a
matter of aligning a good set of procedures with a good tool (I may still be
proved wrong 🙂 ).
>
> If you have all the VIs in a central location and then they're being
edited,
> there's huge scope for things to go wrong and edits to get lost- worse,
you
> can end up with a broken hierarchy if a VI and it's sub-VIs are edited,
and
> then some of the edits are lost. Even if only one person will be editing,
> you can't rule out the possibility of editing a VI that someone has open
on
> another machine, they accidentally perform a trivial change- such as
moving
> a control, or accidentally creating a front panel object and then deleting
> it, and then accidentally save the changes when prompted at shutdown.
> Obviously you could set the file permissions in NT so only the designated
> developer can write to the files and everyone else has read-only access,
but
> this restrictive case seems quite rare.
>
> What I've done here is cobbled together a VI that compares the hierarchies
> on different machines. You recursively scan the two hierarchies (usually
> rooted on user.lib on each machine) and build a list of last mod dates,
> sizes and VI versions. If a file is unique, that automatically gets copied
> across to the machine on which it is missing. If a VI has a higher
version,
> larger filesize and more recent date, that's most likely to be the correct
> new version, and that gets copied across. There's a few other combinations
> that I decided were also good enough bets that they could automatically be
> copied. Any ambiguous files are shown in a list at the end of the run and
> the user has to manually select the "real" version of the program. It's
> slightly unwieldy, but you may want to consider something similar your
end.
>
> A very nice way to do it would be to have a daemon on each client machine
> that's remotely launched by the master machine via VI server. All the
> machines build their own list of VI information and send it to the server,
> which then processes the lists and does the synchronisation on a file by
> file basis, rather than a machine by machine basis. This would be faster
> and, since the server doesn't need to load each file across the network to
> get the VI version, would greatly reduce the network overhead. It does of
> course take significantly more time to implement in the first place 😕
>
>
>
