LabVIEW 2022 Public Beta
No Source Code Control for Mac OS?
@Christina_R wrote:
I haven't used it, but I was under the impression that this is the plugin that you're describing: https://www.ni.com/en-us/shop/software/products/git4g.html
And Windows only..... 😞
Cross platform git is weird with LV. Line endings for the XML files change unnecessarily. The "my computer" keeps changing back and forth from "localhost" (good, transportable) to a specific IP address that may mutate in a DHCP environment causing unnecessary updates. These are LV platform specific inconsistencies that are annoying.
@JimB. wrote:Is it hard coded though? How do the existing SVN/Git plugins work then? Or do they not actually use those configuration settings? (As you can tell, I've never actually used them.)
I know the Viewpoint TSVN plugin uses the Project Provider and has nothing to do with the built-in SCC configuration.
@JimB. wrote:
@Darren wrote:
I don't know that anyone other than NI has ever written a plugin for the built-in SCC system, but it is possible.
Hmmm... Looks like they are under ..\vi.lib\SourceControl\Providers, if any intrepid folks wanted to take a whack at it.
If that's the case then I'd really want to talk to either JKI, or ViewPoint and find out if they know that the SCC built into LabVIEW can be extended. If they did know that then I'd want to know what made them make the decision to use the Project Provider instead. Maybe they know something about the usability, or limitations of that system.
The SCC in LabVIEW predates the Project Explorer, so they might just say that they wanted to use it over the Tools menu, since it is what people use to manage a project after all.
@JimB. wrote:
Hmmm... Looks like they are under ..\vi.lib\SourceControl\Providers, if any intrepid folks wanted to take a whack at it.
And ..\vi.lib\SourceControl\sccapi looks like it has the template for what is needed. But I didn't mean for this to get this involved. It looks like the general consensus is that the built in SCC is useless and unused and all the SCC activity takes place outside of the IDE through a 3rd party app.
I think the suggested best practice is to use Source Tree with git for SCC (especially for cross platform development) and that I should ignore the built in SCM modules unless I want to drag in all the Perforce machinery.
@Darren wrote:
@JimB. wrote:Is it hard coded though?
The Perforce SCC in LabVIEW uses a plugin-based system, so no, it is not hard-coded. There are two plugins that ship with LabVIEW... Perforce Command Line and Perforce SCM. The SCM has all sorts of issues and I've never used it. The command line works well.
I don't know that anyone other than NI has ever written a plugin for the built-in SCC system, but it is possible.
It's certainly possible and I was under the impression that TSVN was also a plugin for that system (and a project provider plugin too) but I may be mistaken. The problem with SCC plugins in LabVIEW was that it was poorly documented and hidden behind a non-disclosure pay wall. I did kind of reverse engineer that plugin back in the days but not having official documentation it didn't seem like a feasible path to follow for future version compatibility.
Another problem with the SCC plugin is that it is very much based on the old Microsoft SCC API with its synchronous check-in and checkout paradigma and isn't very suited for SCC's that don't rely on source code locking and unlocking in a central repository. In terms of GIT it is completely contrary to how GIT is really working and the workarounds to make it work with GIT make the already complicated GIT mechanismes completely obscure.
@Hooovahh wrote:
@JimB. wrote:
@Darren wrote:
I don't know that anyone other than NI has ever written a plugin for the built-in SCC system, but it is possible.
Hmmm... Looks like they are under ..\vi.lib\SourceControl\Providers, if any intrepid folks wanted to take a whack at it.
If that's the case then I'd really want to talk to either JKI, or ViewPoint and find out if they know that the SCC built into LabVIEW can be extended. If they did know that then I'd want to know what made them make the decision to use the Project Provider instead. Maybe they know something about the usability, or limitations of that system.
The SCC in LabVIEW predates the Project Explorer, so they might just say that they wanted to use it over the Tools menu, since it is what people use to manage a project after all.
My guess is that the menu based SCC integration as implemented in LabVIEW isn't exactly feeling intuitive with everyone being used to Tortoise SVN and Tortoise GIT. The ability to directly select SCC operations on the source tree is so much more intuitive than having to go into a central menu and selecting options from it, that it seems a simple no brainer decision if you have access to the project provider plugin documentation. I definitely prefer to work in Tortoise SVN even if it means switching applications than trying to use an SVN SCC provider plugin in LabVIEW if it would exist. It was one of the reason that I never really pursued the idea of creating such a plugin in the first place, even after having found out how a new plugin could be created and added (yes the plugin interface is extendable by adding the correct registration VI for your plugin in the correct place).
