From: MartyS on
Hi all:
 
Does anyone have experience managing a large LabVIEW project using source code control?
 
(1) I've seen some fairly recent postings citing bad experiences using MS Visual SourceSafe within LabVIEW; one solution was to use VSS outside the LabVIEW environment, for checkin and checkout of LabVIEW modules. Is anyone using VSS in a project using LabVIEW 8? LabVIEW 7? How is it going and what are the "gotchas"?
 
(2) A coworker mentioned bad experiences, years ago, using some source code control system with LabVIEW. The problem was that the difference files stored by source code control were comparatively huge for LabVIEW as compared to those for text-based languages. So one big advantage of automated source code control, namely savings of storage space, became a disadvantage. Has anyone encountered this problem in recent versions (7, 8) of LabVIEW?
 
I myself have had bad experiences with LabVIEW's built-in source code control (LV 6.1) and won't use it even if it is available in LV 8. Naturally, I'd rather use source code control than not. VSS, Perforce, CVS are possibilities. Any help is much appreciated.
 
Thanks,
 
::Marty
From: Mareike on
We are using VSS as well. With LV8 we are going to switch to Subversion.

MartyS wrote:

> Hi all:
>  
> Does anyone have experience managing a large LabVIEW project using source
> code control?  
> (1) I've seen some fairly recent postings citing bad
> experiences using MS Visual SourceSafe within LabVIEW; one
> solution was to use VSS outside the LabVIEW environment, for checkin and
> checkout of LabVIEW modules. Is anyone using VSS in a project using
> LabVIEW 8? LabVIEW 7? How is it going and what are the "gotchas"?  
> (2) A coworker mentioned bad experiences, years ago, using some source
> code control system with LabVIEW. The problem was that the difference
> files stored by source code control were comparatively huge for LabVIEW as
> compared to those for text-based languages. So one big advantage of
> automated source code control, namely savings of storage space, became a
> disadvantage. Has anyone encountered this problem in recent versions (7,
> 8) of LabVIEW?   I myself have had bad experiences with LabVIEW's
> built-in source code control (LV 6.1) and won't use it even if it is
> available in LV 8. Naturally, I'd rather use source code control than not.
> VSS, Perforce, CVS are possibilities. Any help is much appreciated.  
> Thanks,  
> ::Marty

From: MartyS on
Thanks for the feedback.
::Marty
From: chrisger on
hi there,
i'm working with LabVIEW 7.1 and TortoiseSVN 1.2.6/Subversion 1.2.3. In general this works great, i'm using the context sensitive capabilities of TortoiseSVN in Explorer Windows or File Dialog Boxes for my file managment cause we got lots of non-LabVIEW files to handle (pictures, ini-files etc.).
But today i did a MassCompile over a versioned Directory Tree. The versioned directories contain directories named .svn that hold the local working status of the versioned file. These directories contain files named <MyLLBName>.llb.svn-base or  <MyFileName>.vi.svn-base etc. It seems that LabVIEW touches these files during a MassCompile (because of the extension i guess) which leads to erros in the SubVersion - Checksums. As a result you have to check out the whole directory tree again and replace the last committed LLBs/VIs with those from the MassCompile. This could lead to loss of work...
 
 | 
Pages: 1
Prev: decorations pumps 3dpipes
Next: PWM Generation