Search the Community

I’m a big fan of JKI VIPM, and I’ve been usen Source code control with labview for some years (First with mercurial and now with GIT). Following the good practices with SCC and LabVIEW I always check the separate compiled code from vi to avoid unwanted changes on Vis. In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project… My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?. Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling Thanks!!

As I've reported in the UI Tools support page, I've started migrating the open source code I still have on bitbucket (Mercurial-based repos) to Github. I didn't think that it might be worth a specific topic until @LogMAN mentioned it. Personally, I'm moving my code to Github in the process. I know there are some reports of Hg-to-Git transitions not going so well when using sub-repositories, so please share your migration experience if you've had to jump into some hoops to get it done! For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:

While creating a new a new repo in GitHub, I noticed there is not a template .gitignore for LabVIEW -- let's make one! After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore. So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request. Here's the contents of the file right now: # http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps How can this be improved?

I am playing with GitHub as a possible replacement for our current SCC tool. Do you guys use Git or GitHub? What client app do you use? Any recommendations? I am specifically leaving the topic scope open, so feel free to praise/rant/headscratch.

Hi, I'm looking for some advice from anyone who has been using mercurial with LabVIEW. Firstly I have just been trying some branching and merging. After a merge, having been configured for merge using https://bitbucket.or...iew-integration I see some .orig files getting left in the repository. Is this a failing on LabVIEWmerge.exe to clean it up or is it the way mercurial works? I am interested in the DVCS camps because of merging. I currently use SVN, primarily as a lone developer. I like not having to maintain a separate central repo and the improved merging, primarily from the point of having sandbox branches. I like that in Git, if I have an experimental branch that doesn't work out I can delete it. Is there a similar workflow with bookmarks that can be achieved or am I going to end up with a load of bookmarks littered around the place? I liked that Mercurial integrates better with Windows and is a simpler way to learn DVCS than Git, but I do also like the look of branching in Git and think the extra flexibility may be a killer feature. That said my general opinion when you get these 'holy wars' is that there is probably no real difference between them, else people wouldn't be arguing so much over minor details! Cheers, James

Hi all, I've recently started using Subverion + TortoiseSVN to manage the source code of LabVIEW projects and I'm now getting to the point where I don't really know what I should do ; untill I had no banches and just revisions and a couple of tags for shipped versions I could handle it. Now I need to go further than that and manage a large project that consist in an EXE and 3 plugins. The EXE will be shipped to many customers and each customer will have different "flavours" of the plugins. I'm not feeling confortable enough with SCC usage to decide how to manage this scenario. Multiple repos? Sub-repos (does it exist?), one repo and 1 branch per customer? The whole source code sums up to about 2000 VIs. The EXE and the plugins have subVIs in common (some that are user.lib and some that are part of the project). Any advice greatly appriciated.

Recently I was tangentially involved in a software management mess where the fact that a 3rd party LabVIEW add on was not in our source control (SVN) made it very difficult to build a new binary of a previous revision. This particular add on has many revisions. It is a work in progress as we and the 3rd party do R&D on the application. In addition they are primarily PhD's in something other the Software Engineering. The code shows this and noteably the pinouts to the applications VIs change from revision to revision. I think the OO jargon for this is Highly Coupled, meaning certain revision of our code work only with certain revisions of thier code. We have a situation where instead of any developer being able to do a build at any time, only one or two machine can succesfully build this project. I was reading other threads on this forum, specifically http://lavag.org/topic/13492-reuse-packages-and-scc/ and it looks like VIPM might be an answer. But I have specific questions about how it would work. Apparently there is a VIPC file that would be committed to SVN or any SCC. When exporting, a developer would use this file in some way to verify that the right version of the packages are installed. Is this correct? What is the "some way"? Will this process downgrade the 3rd party add on as needed? Presumably also the VIPM would in some way make sure there were not two version of the packages in the VIPC, or do something else to prevent cross-linking? So the way I imagine the use would be: Checkout the code from a previous revision. Update the 3rd party add ons to the correct version based on the VIPC file. Build the binary and installer. Delete working folder. Or if a we needed a branch of a previous revision say 5.1 from 5. Checkout version 5. Update the 3rd party add ons to the correct version based on the VIPC file. Make the required 5.1 revisions. Check the VIPC for new dependencies. Build/Test/Validate etc... Commit changes including VIPC. Is that right and does VIPM handle the package updates and dependency checks? Thanks!