FAQ
Before starting on a development project, you should briefly review all of the Developer FAQs:
You should install the following applications:
Developers will use the following paths for working copy checkout locations (the last 2 are only needed for TestStand):
In order to checkout from these repositories, you'll need a Repository Map. Each of the 5 items above has a Repository Map. Please read the Issue Tracker FAQ's to find your Project and Repository Map(s).
Whether you're building in LabVIEW or TestStand, you should NEVER build in any of the National Instruments folders. This especially includes, but is not limited to <user.lib> and <instr.lib>. Building in these folders will yield catastrophic and unpredictable results.
Bolder Software has adopted a practice of using public folders for source code development A good convention to follow here would be something like:
<Public>\<Customer>\LabVIEW_Builds\<Project>
or
<Public>\<Customer>\TestStand_Builds\<Project>
So for a project called "ULIP_SWAGR" at customer "Seakr" the following build path would be used on a Windows 7 platform:
C:\Users\Public\Documents\Seakr\LabVIEW Builds\ULIP_SWAGR
The Issue Tracker is a vital component of Bolder Software. Employees, subcontractors, and customers should understand it's intent:
You may have noticed other user's Avatars. You can easily add your Avatar to your entries by creating an account at:
Once you've created and verified your account, you can upload your Avatar. Your Avatar will automatically appear in the Issue Tracker.
The Project viewer is the easiest way to navigate to Customer Projects, and can be found on the upper left menu of the Issue Tracker.
A tree is displayed. Clicking the "+" expands the tree while clicking on the text does not.
Although other hierarchies can exist, the general hierarchy of the tree is <Customer>\
<Program>\<Project>:
*NOTE* Before getting started with Git, please make sure an administrator has granted you access to the Bolder Software Git repository.
Git can run on many platforms. In this FAQ, we'll assume you're using the Windows TortoiseGit client to access the Bolder Software Git repository. You can get the latest version of TortoiseGit at:
https://tortoisegit.org/download/
Git is a very powerful and complex software solution. If you are new to revision control, or haven't used Git much in the past, you should spend time with other Bolder Software engineers learning and understanding how to use the tool.
However, you can omit the <Project> Folder since TortoiseGit will create it for you, so you would end up with:
With a loose integration to the Issue Tracker, certain expressions can be used during commits to associate the check-in to an existing Issue in the Issue Tracker. Those expressions are:
Refs #<issue_number> (References the comment to the issue)
Fixes #<issue_number> (References the comment to the issue and moves the issue to the resolved state)
For instance, if you typed:
Fixes #1077
- Added case structure for error trapping
- Fixed icon, front panel and block diagram
- Added VI documentation
The result would be that Issue number 1077 would get moved to the resolved state, and a note would be added to the Issue with the above comments, along with the commit list generated by TortoiseSVN. The repository would contain the committed code, and your local workspace would be in sync with the repository.
To perform the check-in, follow these steps:
Commits in Git don't actually commit to the master repository, only the local working copy. When you're ready to add your edits to the master repository, you can do a "Push":
Once you've completed a Release (or an Agile Sprint), and it has been verified or approved, you can tag that version so that it can be checked out from the repository at a later time, and independent of the trunk. Tagging is a simple process, but attention to detail is important during this step since is is usually coupled to an Issue Tracker Release. Follow these steps to tag a version:
Whether you're building in LabVIEW or TestStand, you should NEVER build in any of the National Instruments folders. This especially includes, but is not limited to <user.lib> and <instr.lib>. Building in these folders will yield catastrophic and unpredictable results.
Bolder Software has adopted a practice of using public folders for source code development A good convention to follow here would be something like:
<Public>\<Customer>\LabVIEW_Builds\<Project>
or
<Public>\<Customer>\TestStand_Builds\<Project>
So for a project called "ULIP_SWAGR" at customer "Seakr" the following build path would be used on a Windows 7 platform:
C:\Users\Public\Documents\Seakr\LabVIEW Builds\ULIP_SWAGR
You can add sub-folders for "Application" and "Installer" builds. Make sure to change your destination directory to something similar to the paths above.
For Executables, there is a function built into LabVIEW that can get the version of you compiled executable.The function resides in:
<vi.lib>\platform\fileVersionInfo.llb\FileVersionInfo.vi
*NOTE*, this only works for compiled executables, and will not work in the LabVIEW development environment.
This website uses cookies to ensure you get the best experience on our website.