Native SubVersion Support

[shew82]

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.

[crelf]

I would pay extra for this (heck, I already do with pushOK - which is, as you say, flaky).

[PaulG.]

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

[Lavezza]

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.

[JackDunaway]

This idea is a subset of my original idea.

[rolfk]

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

[rolfk]

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.

[Lavezza]

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.

[Terry_ALE]

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.

[asuwish4]

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 😉

[RobCole]

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.