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”.
>>>>> 
