LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Native SubVersion Support

Subversion is one of the most popular SCC systems in use yet currently LabVIEW can only integrate with the help of rather flakey 3rd party plugins. It would be so much easier if LabVIEW included native SubVersion support, allowing full integration with the LabVIEW Project etc.
16 Comments
Active Participant
I would pay extra for this (heck, I already do with pushOK - which is, as you say, flaky).




Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

(taking a deep breath)

 

NI has no business flirting with open source anything, especially SCC. Leave that to the LAVA and OpenG and the like guru communities to play around with. NI trying to support any open source product could be a huge headache and they would be stuck with it for LIFE. This is Source Code Control for cryinoutloud! That said, having NI work with Perforce (which is the SCC NI uses) to give us Perforce tuned for NI products at a reasonable price could be sweet.

PaulG.

"Without data you're just another person with an opinion." - W. Edwards Deming
Member
Have you looked at TortoiseSVN Tool for LabVIEW™ from JKI? It isn't free, but it might be better than pushOK.

I think a better idea would be to have NI publish an API for integrating SCC systems into the project. Maybe releasing an unsupported example for SVN at NI Labs.

Trusted Enthusiast

This idea is a subset of my original idea.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Proven Zealot

I agree that NI should not get into the SCC business. They did try once going even one step further and creating an entire native SCC solution, which was the start of the now existing SCC plugin interface. While in theory a nice try, the practical use of that provider was minimal and it was consequently scrapped in later releases.

 

I once started with a direct DLL interface to the SubVersion client libraries that would support virtually every SubVersion feature but have after some serious time resolved to just calling the svn client executable over the command line for the build-in version control needs of some of my script based test applications.

 

The command line is a bit tricky at times to use but it can do the job and implementing an SCC provider on top of that for the LabVIEW SCC system would be in fact not a very hard thing to do. I still would prefer the DLL based interface to SubVersion for that. The Pros would be a much tighter and more performant interface to SubVersions, the Cons are an interface that could much easier break with new major versions of SubVersions and a considerable effort to make the LabVIEW<->SubVersion DLL interface. That interface uses Callbacks and complicated datastructures that can not be interfaced directly from within LabVIEW.

 

That all said, JKI has released a LabVIEW SubVersion Tool that integrates in the Tool menu of LabVIEW and might be almost as good as a full LabVIEW SCC integration.
Message Edited by rolfk on 08-13-2009 09:34 AM
Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Proven Zealot
And Lavezza, there is an API for the SCC providers, it just would need to be better documented somehow. If you look in vi.lib/Source Control you will see the API itself and the providers directory. You add an additional Provider directory and for each VI in the sccapi directory you need to implement an according VI in the Provider subdirectory.
Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Member

rolfk,

True. When I said publish an API, I should have said document the API. Right now it isn't a trivial exercise. The funny thing is the P4CMD provider for the Perforce command line would be a great starting point for just about every other heavily used provider out there (CVS, SVN, git, etc.). If the P4CMD library was unlocked and the API was documented, I think we'd see an SVN client fairly quickly. Of course, if someone is resourceful enough it might be doable with what is available.

Active Participant
Yes, this is a much needed feature to LabVIEW.  A lot of LabVIEW users are currently using SVN and it would great to have native support from NI.

Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
Member

As a user of TortoiseSVN, I have to say that the implementation matters.  TortoiseSVN pretty much sends batch commands to the command line behind the scenes, but it's interface is so transparent, that it's a real pleasure to use.  In LabVIEW, I have to agree that the SCC API could use more documentation - and there are more API's in LabVIEW that could use that same treatment ;-)

 

 

Active Participant

I agree that LabVIEW should work with SVN, BUT... Only after SVN better supports binary file formats (like VIs) and *locking* of files. We have 12 developers working at a time and using TortoiseSVN, pushOK and a few others did not work for us. Smaller projects with only a few VIs seemed to work okay, but when we got up into projects with thousands of VIs, SVN ceased being viable.

 

I think NI should support SCC systems that can handle the file formats and locking required for working in LabVIEW.