LabVIEW Idea Exchange

I have seen a few posts online indicating a couple of changes here and there for LVMerge and LVDiff.  I think the main problem is that we just want it to work with third party SCM tools like Mercurial / TortoiseHG, SVN / TortoiseSVN, RTC (Rational Team Concert), Surround, ect.  The ability to check in and out from project explorer is not quite cutting it.  With more and more developers using distributed SCC products like GIT or Mercurial the ability to merge and diff becomes really important.  Here is a list of what I would like to see in newer versions of LabVIEW and the LVMerge and LVDiff tools that would give us more time to develop code and less time spent managing software.

1. Both LVMerge and LVDiff work ok with a single vi, but not that well when hierarchies are different.  Most SCC applications will only download one file or the files that are different between change sets when merging or differencing change sets.  The basic problem is that in order to diff or merge LabVIEW requires the vi to be loaded which requires loading dependencies.  If the merge and diff tools didn’t require the vi’s dependencies to be loaded into memory then many of the issues just go away.

 I understand the technical challenges in order to implement this feature, but I think it would be a far better approach then trying to write a huge amount of code in order to handle multiple SCC tools.  Even if that code was written the workaround solutions are not pretty.  For example you would have to download both change set’s entire hierarchies to disk and then compare them.  How well will that work with very large projects?  Or with a merge where you need three version of the hierarchy?

I think the better solution is to just make LabVIEW files act like text files when diff and merges are performed.  The information in the LabVIEW file points to dependencies, and if those dependencies’s attributes change then flag them, but LabVIEW should be able to generate the LabVIEW "file" in a vacuum for differencing and merging.  May require caching more information about dependencies then what is currently saved in the vi, but I think that would allow a better merge / diff utility.

2. Support differencing and merging of all LabVIEW file types (projects, xctls, classes, libraries...).  Sometimes the text merge features in some programs don't take into account the complexity of the relationships between LabVIEW files.  It would be nicer to have a visual diff in terms of how LabVIEW treats the file (e.g. how TestStand differences sequence files).

3.  This is more of a bug fix, but improve the merge windows.  I have found a couple of situations where the code being merged is not even shown in the three windows (base, theirs, mine) and I cannot scroll to that location in the code to intelligently perform the merge.

4. LVMerge exe exits right away before the merge is complete.  TortoiseHG thinks the merge is complete for a file when the exe exits so it blows right past all of the other file merges so only the first file is merged.

5. Cover these use cases as differences between change sets when merging and differencing (item 1 solution should cover these):

Setup: use TortoiseHG to difference an entire change set in the repository with the local drive, or merge two change set in the repository.

• Moved files (not just vi's) in the hierarchy
• Deleted files in the hierarchy
• Files added or removed from classes/libraries/projects
• File 1 changed and dependency File 2 changes it's connector pane connection to work with the changes in file 1
• Both new change sets add the same file that the base change set does not contain
• Same as the last item, but added file has a different location on the hard drive between the change sets

There are probably more that I am not thinking of, but that would be a good start.

6. Simplify the entire process by providing a real IDE for merging and differencing files.  I am envisioning something with a hierarchy of views like Beyond Compare.  It would allow you to simplify some actions at a high level, but would give you the power to perform advanced actions.  For example, present a list of differences, types of differences, and the types of merges possible. 

• Maybe some files can be auto-merged
• SCC thinks the files were different but there are only cosmetic changes
• User could choose between a deleted file or a changed file
• Two versions are different but the user knows which one to choose without performing a merge.

The user should be able to have a quick view (no loading dependencies), or double click on the item and a new tab comes up that allows an actual file merge (vi, class, project, ect.).

 I think a tool like that that has the ability to interface with third party SCC tools would be a huge timesaver especially when dealing with distributed environments where merges occur more often.  It may need to stream all of the changes from a tool like TortoiseHG before performing a merge (probably easiest implementation), or rewrite the GUI for managing Mercurial or GIT change sets directly.

 The other option is to say "just use a check in check out central repository SCC", and I would say Phooeey! to that.   After using Mercurial with TortoiseHG for a while I would not switch to anything other then another distributed SCC application...even with the difficulties with the merges and differences, using another system still poses similar problems (sometimes even worse) and the software management in those programs just stifles productivity.  Has anyone ever tried to move a class and its members to a different directory after the code has already been checked into an SCC tool like Perforce?  How about managing a multi-branch project where stable release updates are not only applied to the trunk but to a major feature branch?  Painful...

I think that these changes to the LabVIEW development environment will move us from “writing LabVIEW code” to “software development using LabVIEW”.

Title pretty much says it all.  It would be a fine companion for the proposed Noncommercial Hobby/Home license for LabVIEW.

I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references.  It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).

I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.

The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).

Could be very nice for scripting.

For Reports it is only possible to set one with for all columns. It would be nice if the polimorphic VI "Append Table to Report.vi" would support column with for multiple columns too. Several VIs would have to be copied and adapted.

For a standard report, the VI replacing "Set Table Column With.vi" would look like this:

The functionality to adapt to the page with if the column with is too big is lost when different withs are set. But probably NI could fix this too.

Greetings,

shb

We use NIRG a lot, and I'd like to move away from what looks like random free text on the block diagram to a text block that's instantly recognizable as a requirement.  Kind-of related to this idea, but specific to NIRG.

This is something a few power users have asked me about. There's no Instrument Driver or VIPM Idea Exchange, so I thought I would post it here.

What if VIPM could manage Instrument Drivers from IDNet?
There are a few key benefits this would offer us...

• download IDNet drivers directly from VIPM 
• track which version of a driver you are using for different projects and revert when necessary 
• wrap up ID dependencies in a VIPC file for use at a customer site