LVMerge with remote target and SVN

[jtay]

I am currently learning how to use TortoiseSVN with my project in LabView 2009. At the moment I am not using any of the toolkits available for integrating TortoiseSVN with LabView, but I may in the future. It appears that LVMerge has issues with working with VIs that are on an RT target in the LabView project. Here is my process:

1. Perform an SVN Update to get the latest version of my code from the server

2. Open the LabView project

3. Make a small modification to a VI in the project that is on my RT target

4. Save the change and commit it to SVN.

5. Update SVN to the version of my code prior to the commit I just did.

6. Make a small, but different, modification to the same VI I did before.

7. Save the change and perform an SVN Update.

This causes a conflict, which is what I was trying to do. I should note here that TortoiseSVN is calling LVcompare and LVmerge using the method escribed on this page:

LVCompare command -

"C:\Program Files\National Instruments\Shared\LabVIEW Compare\LVCompare.exe" %mine %base -nobdcosm -nobdpos

LVMerge command -

"C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe" %base %mine %theirs %merged

Now I do an SVN Commit, which pops up a dialog where I can double click on the conflicted VI and merge it. When I do so, LVmerge runs but does not behave properly. It either hangs and I have to end its process, or it crashes LabView. It does not behave this way if I use it to resolve conflicts on VIs that are on the PC rather than the RT. Is there a way I can use LVMerge on VIs on the RT target without this behavior? Do any of the toolkits for integrating TortoiseSVN and LabView work around this issue? I intend to try one of the toolkits soon to find out.

[Norbert_B]

I am not aware of situations like this.

If i understand correctly, you say that the same VI does NOT create the merge issue if put into the "MySystem" target in the lvproj?

That is rather odd, as the VI itself is not aware about "where it is located in the project explorer". Without the project in memory, the VI is "simply a VI".

That being said i am wondering about two things:

a) Is the issue connected to the lvproj-file being opened in the background?

b) Is the issue connected to a specific function/DLL called in that specific VI?

Norbert

[Intaris]

I have also had cases where LVMerge either crashes out ot hangs indefinitely.

I have never quite found out what leads to the problem (hence no bug report) but I just want to say that I have on several occasions observed the same problems.

Shane.

[jtay]

After further investigation today, I found what I believe is causing LVMerge to fail to run properly or crash LabView.

LVMerge displays an error and fails to run properly when all of these conditions are met:

The project window is open.

The VIs that LVMerge is operating on are part of the project.

The VIs reside on an RT target in the project.

The VIs have been run since the project was opened.

Closing the project allows LVMerge to run successfully on the VIs. Closing LabView also allows LVMerge to run successfully.

LVMerge crashes LabView when all of the following conditions are met:

The VIs reside on an RT target in a project. (The project doesn't have to be open, however.)

The VIs contain conditional disable structures that contain different code for when the VI is run on Windows or on an RT.

Removing the diagram disables, leaving only the RT portion of them, allows LVMerge to run successfully.

This issue is independent of SVN. I got this behavior when calling LVMerge via the command line. I would be interested to know if this behavior is also present in newer versions of LabView. If you have any recommendations for workarounds, so I can use LVMerge on VIs with diagram disables on the RT, I would appreciate it.

[Norbert_B]

Do you have the option "separate compiled code" set?

Norbert

[jtay]

I am using LabView 2009. It appears that the feature to separate compiled code was not added until LabView 2011.

[Norbert_B]

It was added as new feature in LV 2010.

This might be an indication as you have the compiled code within the vi-files. Which essentially requires a recompile of the VI you modify during the merge process.

I find it possible that specific interfaces, which are only valid in the project context, are misinterpreted by the merge tool as it does not care about the project context (at least as far as i know).

This could lead to incompatibilities esp. if the context of the project is in memory during the merge process.

Also, target specific settings might be an issue, quite the same reason here i assume.....

So there are two questions left:

a) Can you update to LV 2013 and see if the behavior is still present? If so, does it change if you separate the compiled code from all VIs before using source code control and ultimately the merge?

b) If question a) does not solve the issue, can you provide a small example which shows the behavior in a reproducable way?

thanks,
Norbert

[jtay]

I will be installing LabView 2013 in the near future, and when I do I will see if the issue is still present and if separating compiled code helps.

For the time being, if I need to merge RT VIs, I will have to close the project before attempting to merge. And if those VIs have conditional disables, I will have to close LabView, open each of the VIs outside of the project, and resave them before attempting to merge.