LabVIEW 2022 Public Beta
No Source Code Control for Mac OS?
Looking for improvements in source code control and VI comparison merge. But in the preferences I only get the option none. There is git installed on the machine and I use it through SourceTree. There are some weirdnesses of trying to get git to ignore different line endings in some of the project files....
But the only option in the preferences is "none".
@Christina_R wrote:
Currently, the only source control provider that LabVIEW integrates into the editor on non-Windows platforms is Perforce.
That was the missing piece of information. I was assuming that you would support git as one of the most prevalent SCC systems. Or even hg. But Perforce is a more commercial (and expensive) system and I did not know that it is beginning to support other platforms and maybe should look into it.
Would it be that difficult to integrate the git as a SCC API? I would think it easier than Perforce with all the overhead instead of the relatively simple git calls. But YMMV.
@sth wrote:
@Christina_R wrote:
Currently, the only source control provider that LabVIEW integrates into the editor on non-Windows platforms is Perforce.
That was the missing piece of information. I was assuming that you would support git as one of the most prevalent SCC systems. Or even hg. But Perforce is a more commercial (and expensive) system and I did not know that it is beginning to support other platforms and maybe should look into it.
Would it be that difficult to integrate the git as a SCC API? I would think it easier than Perforce with all the overhead instead of the relatively simple git calls. But YMMV.
The Perforce integration has been in LabVIEW for a VERY long time. From my understanding, NI was using Perforce. Therefore they were more inclined to have built-in support for Perforce.
Looking at the options for configuring source control options (in 2021 and 8.2), I'm actually a little surprised to see Surround SCM in the supported tools, which we use here for project documents.
I wonder how much glue is needed to stick in support for more common SCC systems such as git (hg, svn etc.). Here is a good project for G-Central to farm out to enterprising coders. (or a summer intern project at NI?)
I would really like a good SCC and have ignored this for too long. I mostly worked alone for many years. About 2 years ago, I started putting new projects on a git server and collaborating/archiving code for others. I will continue to use SourceTree as my GUI for git but I always wondered what the advantage of using an internal SCM within LV was. Hopefully the new integration with Compare/Merge?? Maybe there isn't much advantage to that internal SCM.
@sth wrote:
I wonder how much glue is needed to stick in support for more common SCC systems such as git (hg, svn etc.). Here is a good project for G-Central to farm out to enterprising coders. (or a summer intern project at NI?)
I'm under the impression the Hg is pretty much dead.
There are tools available for adding SVN support by Viewpoint and JKI. It looks like they both are made for Tortoise SVN.
So then the question is really with Git. If there are already SCC hooks, I don't see a reason it couldn't be opened up for somebody to make a plugin.
@crossrulz wrote:
I'm under the impression the Hg is pretty much dead.
There are tools available for adding SVN support by Viewpoint and JKI. It looks like they both are made for Tortoise SVN.
So then the question is really with Git. If there are already SCC hooks, I don't see a reason it couldn't be opened up for somebody to make a plugin.
I don't see much future for Hg (or SVN and CVS is really gone). Git is probably the most widespread at the moment. However in thinking ahead the plugins should be easily modifiable to handle future opportunities and not committing to Tortoise SVN for example.
Just my $0.02 worth. This is really part of the debate on "Info-LabVIEW" back in the 90s when the question was "Is LabVIEW a real programming language?" What are the necessary parts of an IDE that make something a "real language"? Still don't have a complete answer but SCC was one of them.
SCC in LabVIEW is one of those features I see that lots of work was put into, and then no one uses. In my 18 years of LabVIEW I saw one company use it for one project. Often I'll teach LabVIEW and someone will find that menu only for me to say how no one uses it. It either needs to be modular and open for extension, or it shouldn't exist. Coding practices and tools mature all the time. Adding support for SCC and then only hard coding a couple tools will result in the IDE feeling dated in a few short years. Or in this case a couple decades of stagnation. I was surprised to hear that any SCC worked in Mac. If NI used Perforce, I guess it is expected that it is the only one. I get why NI doesn't remove the feature, but maybe they should disable the menu item by default or something.
@Hooovahh wrote:
SCC in LabVIEW is one of those features I see that lots of work was put into, and then no one uses. In my 18 years of LabVIEW I saw one company use it for one project. Often I'll teach LabVIEW and someone will find that menu only for me to say how no one uses it. It either needs to be modular and open for extension, or it shouldn't exist. Coding practices and tools mature all the time. Adding support for SCC and then only hard coding a couple tools will result in the IDE feeling dated in a few short years. Or in this case a couple decades of stagnation. I was surprised to hear that any SCC worked in Mac. If NI used Perforce, I guess it is expected that it is the only one. I get why NI doesn't remove the feature, but maybe they should disable the menu item by default or something.
I'm sure I've said this before, but I would like NI to spend some time removing obscure/unused features. This would make the actual install smaller and remove weird interactions in the code base.
In the case of the SCC, I would like to see the actual implementations removed from the LabVIEW core and just leave hooks for whoever to make plugins for whatever SCC tool is desired. As part of this effort, NI could move the current implementations into plugins available through VIPM or even NIPM.
