Source Code Control in LabVIEW 8

[Jim Kring]

I was reading the online tutorial Using Source Control Software with LabVIEW, which describes the SCC features in LabVIEW 8. It looks like LabVIEW will support any SCC API Plug-in (SCC API is a Micro$osft standard for source code control providers to plug-in to a development IDE). The tutorial states that the following are supported:

• Microsoft Visual SourceSafe
  
• Perforce
  
• Rational ClearCase
  
• PVCS (Serena) Version Manager
  
• MKS Source Integrity
  
• CVS with the PushOk Windows client software
  

I am pretty excited about having CVS support, since OpenG developers use CVS. But, I am also excited because there is a good chance that the PushOK SVN SCC proxy (which I discovered on the PushOk website while looking into thier CVS SCC proxy product) will also work, allowing LabVIEW's SCC to talk to Subversion! :thumbup:

[Jim Kring]

I just downloaded the PushOk SVN Proxy and I couldn't get it to work -- probably because it is having trouble with snv+ssh URLs (svn tunnelling through ssh, which is the access mechanism that I use for accessing my repository). Also, I am not liking the LabVIEW approach to source code control. The Source Code Control settings are a global LabVIEW setting (configured in the Tools>>Options... dialog), rather than a project setting. Since LabVIEW 8 has projects, why are Source Code Control settings global? This doesn't make sense to me.

I'm thinking that I might just ditch the idea of using LabVIEW SCC and just keep using TortoiseCVS and TortoiseSVN -- the way I've always done it. Also, since CVS and Subversion use a concurrent access model (update/commit) rather than a synchronous access model (check-out/check-in), I am not sure that I would like limiting myself to the latter by going through the SCC API.

[jpdrolet]

... Also, I am not liking the LabVIEW approach to source code control. The Source Code Control settings are a global LabVIEW setting (configured in the Tools>>Options... dialog), rather than a project setting. Since LabVIEW 8 has projects, why are Source Code Control settings global? This doesn't make sense to me.

I don't know about LV8 yet but the old SCC stored its settings in the default directory so all projects were sharing SCC settings/repository if you let the default directory to be the LabVIEW directory. It was better to have each project with its own default directory (usually the project directory)

[Khalid]

... Also, since CVS and Subversion use a concurrent access model (update/commit) rather than a synchronous access model (check-out/check-in), I am not sure that I would like limiting myself to the latter by going through the SCC API.

How, in your opinion, is "update/commit" better than "check-in/check-out"? We can't merge VI diagrams..

Just trying to understand as I have always used the latter (with Perforce).

Thank you,

-Khalid

[djolivet]

I would like opinions on this too....

How, in your opinion, is "update/commit" better than "check-in/check-out"? We can't merge VI diagrams..

Just trying to understand as I have always used the latter (with Perforce).

Thank you,

-Khalid

[Jim Kring]

How, in your opinion, is "update/commit" better than "check-in/check-out"?

update/commit is better than check-in/check-out for many reasons:

1) update/commit requires good communication between developers, which facilitates communication between developers.

2) locking large portions of code causes limits access to those portions of code, even if they are not being changed. It forces synchronous access to large blocks, which slows down development.

3) locking/unlocking requires access to the repository, therefore you cannot checkout code and do development unless you have connectivity to the repository. The update/commit model only requires access to commit the changes. You do not need access at the time you decide to make changes.

We can't merge VI diagrams...

Yes you can. Take a look at lvdiff, which allows side by side comparisons of VI differences.

[m3nth]

Lvdiff requires this file in your project directory:

procmphier.llb\CMP compare two VIs.vi

Since I don't have that file, I'm guessing it's probably in the SCC toolkit or something like that and a good majority of people probably don't have it.

[Jim Kring]

Lvdiff requires this file in your project directory:

procmphier.llb\CMP compare two VIs.vi

Since I don't have that file, I'm guessing it's probably in the SCC toolkit or something like that and a good majority of people probably don't have it.

Sounds like you don't have the Professional version of LabVIEW.

[m3nth]

Sounds like you don't have the Professional version of LabVIEW.

Don't be such a snob. You're right, I don't have the professional version, and that's a good explanation as to why I don't have that file.

You know, I was just thinking today about how expensive LabVIEW is. It is REALLY expensive. And I was thinking, why does NI charge that much for it? And the answer in my opinion is just because they can. Not because it's really that super duper special or extra-functional (although maybe it's headed that direction in version 8), but because huge corporations will shell out the dough for it. And if you don't work for a huge corporation, or an educational institution (do they give out pro copies to educators?), then you're screwed. Which is why many people are still using 7 and won't be able to go to 8. Or why they're using even earlier versions and haven't gone to 7. And what does NI do for them? It screws them over especially bad because none of the new files open and nobody can back-save past one version. I'll get off my soap box now.

[Jim Kring]

Don't be such a snob.

I didn't intend to imply that anyone wasn't a professional, if they didn't have the LabVIEW Professional Development System. I only meant to highlight that "Professional" is a distinct version of LabVIEW -- I didn't pick the name, so don't blame me.

Speaking of snobbery, what entitles you to use LabVIEW? Why should NI price it at a point that you can afford? Do you deserve LabVIEW? If you know of a better/cheaper tool than LabVIEW, then use it. If you see a market for a better/cheaper tool, then build it.

[Khalid]

Yes you can [merge]. Take a look at lvdiff, which allows side by side comparisons of VI differences.

Hi Jim,

I use LVDiff -- it only facilitates in comparing the two VIs by highlighting the differences. We cannot merge changes from one VI into another, like we can with text files (C/C++, for instance). Merging VIs automatically would be quite involved.

I like the check-in/check-out paradigm because my team mate then knows I am working on it. And he can either wait for me, or come talk to me. In update/commit, I am guessing we would end up manually merging changes from one into another.

I guess it all boils down to personal preference.. and/or company policy.

Regards,

-Khalid

[Jim Kring]

I use LVDiff -- it only facilitates in comparing the two VIs by highlighting the differences. We cannot merge changes from one VI into another, like we can with text files (C/C++, for instance). Merging VIs automatically would be quite involved.

Yes, sorry if I overstated things... but, LVDiff really helps you find the difference points and merge manually.

I like the check-in/check-out paradigm because my team mate then knows I am working on it. And he can either wait for me, or come talk to me. In update/commit, I am guessing we would end up manually merging changes from one into another.

Notification that a portion of code is being edited can be achieved using various other mechanisms. For example, you can use the back-end repository hooks of CVS or Subversion to send emails when code is committed or an edit/unedit command is sent.

I guess it all boils down to personal preference.. and/or company policy.

If you have a chance, I recommend taking Subversion for a test drive -- I gaurantee that you will like TortoiseSNV (if you are a Windows user). You can quickly test it out, using a local repository (doesn't use a server, but rather, a location on your hard drive as the repository). Regarding company policy... well, I can't help you there However, you could use another SCM system for your day-to-day work, and then push your code to the official corporate repository once you have achieved milestones.

[gmart]

I have recently tried PushOK's SVN plugin with LabVIEW 8.0. After some configuration headaches (mainly due to not knowing Subversion's semantics), I got it configured and working (check in/out, etc). It is fairly identical to their CVS plugin. I tested it locally and not with a *real* server setup so your milage may vary.

[Rolf Kalbermatter]

Hi Jim,

I use LVDiff -- it only facilitates in comparing the two VIs by highlighting the differences. We cannot merge changes from one VI into another, like we can with text files (C/C++, for instance). Merging VIs automatically would be quite involved.

I work on and off on a few CVS managed projects including Wine and OpenG and even for text based programming merging is often not seamless. If you happen to have (even cosmetic changes) in the neighbourhood of changes made to the repository you end up with conflicts you have to merge manually too. As such the manual merging required with lvdiff isn't actually that much worse.

I like the check-in/check-out paradigm because my team mate then knows I am working on it. And he can either wait for me, or come talk to me. In update/commit, I am guessing we would end up manually merging changes from one into another.

I guess it all boils down to personal preference.. and/or company policy.

If your mate is working down the aisle this may be an interesting work model but with distributed development as is used in most Open Source projects this is not a good solution. And once you get used to the update/commit model the checkout/checkin model doesn't look that attractive anymore. And yes it is a big question of personal preference (and sometimes company policy) although real developers tend to ignore company policies quite easily for all kinds of reasons, even artificial ones ;-)

Rolf Kalbermatter

[brent99]

I just want to opinion that I disagree a bit about the "overpriced" rant. I've paid for toolkits with 1% of the fraction of Labview that cost over $1,000. The less expensive non-pro version provides a great deal (if not all) of the functionality required for most independent developers.

If you want to talk expensive, look at Micro$$$. With their monopoly, you'd think they wouldn't bludgeon you for compiler IDEs that should be free with the OS anyway.

[Marcel_J]

Yes you can. Take a look at lvdiff, which allows side by side comparisons of VI differences.

It's a long time ago that I tried lvdiff, but a comparison alone is not really enough.

For it to be really useful, I think it should be possible to also create patches (from cvs for example) and you should have the ability to apply those patches to a set of VI's.

To get back on the topic: I use CVS for all my projects (which are not only using Labview and not restricted to Windows as well). On windows I use TortoiseCVS as a client. I've been using this for many years now and from what I've checked I think that only subversion may at some time replace this for me. I certainly will never use a M$ solution again for this purpose because I've had a very bad experience with sourcesafe (crash, causing a corrupt database).

[Jim Kring]

It's a long time ago that I tried lvdiff, but a comparison alone is not really enough.

For it to be really useful, I think it should be possible to also create patches (from cvs for example) and you should have the ability to apply those patches to a set of VI's.

Feel free to write a LabVIEW merge tool and post it here, once it's ready.

[orko]

Feel free to write a LabVIEW merge tool and post it here, once it's ready.

:worship: LV Merge! :worship:

We can only wait and hope that it is in the works behind NI's curtain...

Joe (orko)

[Jim Kring]

:worship: LV Merge! :worship:

We can only wait and hope that it is in the works behind NI's curtain...

Joe (orko)

Text merge is easy. LabVIEW merge is very hard. Don't expect it to come from NI, unless they will make money off of the feature.