How do I prevent the overwriting of new vi's with old vi's?

[Adam Russell]

At our company we now have 2 labview programmers -- me and my boss. We soon
will have 2 more. We are worried that we will lose work if some files get
overwritten by older files. The thing is that people write programs on
several machines and then copy whole directories up to the net directory or
sometimes from one machine to another. If one person rewrites a program on
one machine and someone else rewrites a program on another machine (perhaps
even the same program), then they both copy to the net directory one may
lose their work. Even worse, if an old program is written back onto a
machine then we may take bad data till the error is discovered! Does anyone
have any suggestions or strategies
for this problem?

[C Bauman]

Adam Russell wrote in message ...
>At our company we now have 2 labview programmers -- me and my boss. We
soon
>will have 2 more. We are worried that we will lose work if some files get
>overwritten by older files. The thing is that people write programs on
>several machines and then copy whole directories up to the net directory or
>sometimes from one machine to another. If one person rewrites a program on
>one machine and someone else rewrites a program on another machine (perhaps
>even the same program), then they both copy to the net directory one may
>lose their work. Even worse, if an old program is written back onto a
>machine then we may take bad data till the error is discovered! Does
anyone
>have any suggestions or strategies for this problem?
>

What you
are referring to is 'configuration management'. Typically, the
"official" VI libraries (separate the Labview-supplied from
company-developed) would be in a read-only directory. Any modifications
would be given a different name and remain with the project they were
written for. The released version of a project would be archived as a
complete unit in a read-only format. Any updates to a project should start
from the archived version. If deemed necessary, new VIs can be added to the
library with no real problem, but replacing old VIs with modified ones
should only be done if they are compatible, otherwise give them a new name.
While Labview versions I've used weren't made to implement a configuration
management effort, you can develop a programming policy that will do the job
just as well. This is just an overview, you should be able to fill in the
details yourself.

good luck,
-CB

[Greg_McKaskle2]

> At our company we now have 2 labview programmers -- me and my boss. We soon
> will have 2 more. We are worried that we will lose work if some files get
> overwritten by older files. The thing is that people write programs on
> several machines and then copy whole directories up to the net directory or
> sometimes from one machine to another. If one person rewrites a program on
> one machine and someone else rewrites a program on another machine (perhaps
> even the same program), then they both copy to the net directory one may
> lose their work. Even worse, if an old program is written back onto a
> machine then we may take bad data till the error is discovered! Does anyone
> have any suggestions or strategies for this problem?

You may want to look into upgrading to the Professional version of LV. It
includes tools for Source Code Control(SCC) along with documents that describe
various techniques for group development. The Pro verison includes
tools that
help with group development. The tools fit reasonably well with KISS development
procedures, and can also be used to form strict tracability processes
for the
code when that is necessary. This allows you to adopt the different procedures
over time as you want and can adapt them to your group's style of working.

The simplest tool uses a file server, the net directory, but instead of copying
up all of the files, it keeps track of download dates and does date comparisons
so that it can upload only the changed files, and warns when a file on
the server
has been changed by someone else and by you. The Professional edition also
has a tool for comparing two VIs to see the differences between them; so
that the independent changes can be combined, losing no work.

Beyond that, it also supports a couple standard SCC tools like Source
Safe, so that you can keep multiple versions on the server in case you need
to quickly access old VI versions. It includes other stuff too, but that
is what web pages are for.

Greg McKaskle

[Erik Jan de Jong]

No clear answeres here but just a try.

First point, The danger you describe is very real!! I did lose some work
just by keeping a backup of some of the VI's afther which Labview started to
look in the wrong directory and screwed everything up. The likelyness of
this will increase when more people work on it.

One way of solving is by having good communications, seperate individuel
back-ups
so you can restore the errors better and sperting the work in a number of
more or less individuel Vi's which are each writen to there own file. Try to
prefent putting everything in one big libraray (At least while you are
developing)

Other thing is that the new labview has an advanced edition in which they
claim to have build in some features to tackle at least some of these

problems. Inform with NI for more details.

> At our company we now have 2 labview programmers -- me and my
> boss. We soon
> will have 2 more. We are worried that we will lose work if
> some files get
> overwritten by older files. The thing is that people write
> programs on
> several machines and then copy whole directories up to the
> net directory or
> sometimes from one machine to another. If one person
> rewrites a program on
> one machine and someone else rewrites a program on another
> machine (perhaps
> even the same program), then they both copy to the net
> directory one may
> lose their work. Even worse, if an old program is written back onto a
> machine then we may take bad data till the error is
> discovered! Does anyone
> have any suggestions or strategies for this problem?

[Rick Nelson]

....another solution is to do what we do -- buy a third party application that
works with source control. We use Microsoft Visual Source safe for nearly every
program/document we produce, and it works well. It might be expensive, though,
so I don't know if it's a "cost-effective" solution. Our company is 35 people
and we afford it -- MS might just charge you for the # of people using it.

Rick
--
Chesapeake Sciences Corp.
1127B Benfield Blvd.
Millersville, MD 21108

Tel: (410) 923-1300 x3430
Fax: (410) 923-2669