Source code control, LV8

[MartyS]

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, 😎 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

[smercurio_fc]

I've always used SourceSafe primarily due to convenience: we had it as part of Visual Studio. I have not yet done a project with LV 8 but I have never run into major problems or bad experiences using SourceSafe with LabVIEW, and have used SourceSafe with LabVIEW 5, 6, and 7. Any problems had to do with SourceSafe itself, and not the combination. During one project a long time ago we were encountering problems with files being corrupted when checked into or out of SourceSafe. This was with LV 5 and using the SourceSafe client. It turns out the problem had nothing to do with SourceSafe or LabVIEW. The problem was that the network protocol between the workstations and the server was falling back to IPX/SPX instead of TCP/IP. Once I got rid of the IPX/SPX protocol we encountered no further corruption of files.

I did try using SourceSafe in the integrated mode with LabVIEW, but ended up just the SourceSafe client independently. This was due to the fact that I was usually checking out hierarchies as opposed to individual VIs at a time, so it was more of an issue of practicality than lack of functionality or broken functionality.

I have never used the built-in source code control that LabVIEW had because it was... well, you know what they say about not saying something if you don't have anything good to say about it.

As for the file sizes, this is not a surprise since SourceSafe has to treat the files as binary files, and not text files, so the change files are going to be bigger. This will likely be true regardless of the source control program you use. I say this because I've looked at other systems, like Perforce and CVS and they're all pretty much coming from the text file source code control mentality.

Bottom line: It doesn't really matter which system you use: as long as you use one. Each one is going to have its own quirks. The choice usually comes down to one of familiarity. For example, CVS is heavily Linux-based, and even though it's been ported to Windows it still shows it in terms of its usage and documentation. SourceSafe is primarily geared for really small groups - it's not an enterprise-level source code control system, and was never designed to be. We did, however, use SourceSafe to manage a project that was about 2000 VIs, so there you go.

Message Edited by smercurio_fc on 02-21-2006 10:12 AM

[Mareike]

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,
> 😎 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

[MartyS]

Thanks for the feedback.

::Marty

[chrisger]

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...