LabVIEW
Version Control
We used SVN for several years and have recently begun making the switch to Git. It's been "clicking" a lot better for me than I thought it would, and I like it a lot better. I used TortoiseSVN, but now just use Git via the command line.
The "Git book" (https://git-scm.com/book/en/v2) is actually very good. It clicked things in a way none of the videos or tutorials did, and it'll only take a couple hours to read.
@GerdW wrote:
Hi naofomi,
@naofomi wrote:
What is the proper way to do version control with LabView?
Any way you like. Important is only to use version control with source code!
(We currently use SVN, but switch to GIT for new projects.)
What do you use for your build artefacts? We don't have a separate "artefact storage" location, so we've been putting that stuff (installers, etc.) into our tags. Seems to work fine for now.
OP, the most important thing is to just use something. You won't have an opinion on Git vs. SVN until you've gotten the hang of one of them. I'd recommend Git, as it's much more popular than SVN right now (and is my personal preference), but really either one will be MILES better than none at all.
Git also has the benefit of Github being freely available. SVN will require you to run a server somewhere yourself. You can run one locally on your own computer, but it's not exactly ideal.
As for reuse code, I'll repeat what I was told when I started this journey... for now, just copy it all over. Don't make it more complicated than needed.
After you get the hang of it, you can move your libraries into VIP's that can be installed as needed, but you'll be fine coasting along with the "just copy all of it between projects" technique for now.
@Kyle97330 wrote:
A few things to note about Git which made my company decide not to use it:
1. Git has some amazing text-based tools that are worthless with LabVIEW files because it sees them as binaries.
2. Git doesn't accept large files without a lot of shenanigans. If you think you want to store anything large, such as compiled EXE files, consider this first. Since we wanted to archive EXE files to restore old versions as needed without rebuilding EXEs, this was a problem for us.
3. My company does some defense work. While Git has the option to host on premises with some special servers and software, I was told that the complication of this plus the fact that Microsoft still retained some control over even local servers made it unacceptable (I didn't get details).
For those reasons, we went with SVN. If those situations don't apply to you, the decision might be less clear.
My company does the same thing, and initially went with SVN for the same reasons, but recently switched to GitLab. To your point 1, neither Git nor SVN are good at diffing, so that one's moot. For number 2, GitHub has a limit of 100 MB. GitLab cloud has a similar restriction but... for #3, GitLab has a 100% free, open-source tier that you can fully self-host on-prem. You can remove the file size limits and you maintain total control. We switched to that for our smaller team and so far I much prefer it. I might hate it in a year or so, but so far so good!
@Kyle97330 wrote:3. My company does some defense work. While Git has the option to host on premises with some special servers and software, I was told that the complication of this plus the fact that Microsoft still retained some control over even local servers made it unacceptable (I didn't get details).
I work for Northrop Grumman and we use a corporate GitHub server with reduced features. I have yet to have any issues with it. We also have a bunch of programs on secure networks that have their own GitLab servers. So there are plenty of options for you there.
@Kyle97330 wrote:2. Git doesn't accept large files without a lot of shenanigans. If you think you want to store anything large, such as compiled EXE files, consider this first. Since we wanted to archive EXE files to restore old versions as needed without rebuilding EXEs, this was a problem for us.
Executables and installers should be added to releases/tags, not directly in your repo. This is a lesson I recently learned and it has helped quite a bit.
A couple of other notes:
- There is a git command to convert an SVN repo into a git repo. I would need to dig around to find the exact command, but I used it to convert several repos from SVN to git when the GitHub server was being shoved down my throat.
- I really like using Fork as a GUI for managing my repos. I even went as far as to buy my own license to use it in my daily work.
@crossrulz wrote:
Executables and installers should be added to releases/tags, not directly in your repo. This is a lesson I recently learned and it has helped quite a bit.
This looks to be something of a pain in GitLab. In GitHub, (I think??) you can just commit and upload an executable. GitLab seems to make you upload it to some other registry thing.
Do you have any pointers on LabVIEW-specific executable/installer management? Committing to the repo alongside the code is quite easy, especially compared to the "make a fully separate project that only exists to hold a package registry" method GitLab seems to be pointing me to.
Edit: Duh. The "add file" is just hidden in the "release notes" part of the Releases page. I'm not sure this is exactly what they want me to do, but I suppose it'll work:
We are using Team Foundation Server and GitHub (corporate account).
By the way, can someone recommend a provider to integrate these SCC into LabVIEW like it is possible with ancient Microsoft Source Safe and Perforce:
?
