LVmerge needs option to accepts changes from both target and source.

[AnthonyDeVries]

LVMerge often can't handle a situation where I want to accept changes from both target and source.  (And where obviously, they are not conflicting with each other)

I have post already about the problem with enums.   When both target and source added an option in the enum, LVMerge does not allow me to accept both.   I need to either accept the source or the target.   That's really silly...  It should be possible to simply accept both, as it does not create a conflict within the vi to extend enum. 

Also...  LVMerge only indicates that something has changed in the enums, but not what has changed.  When you have an enums with >20 items, it's difficult to figure that out.   It really should highlight the changes in the list... 

A similar problems exists for cases. When your vi has a case selector which a large number of cases, then LVMerge doesn't allow to accept the situation where both target and source have added a (independent) case.  It wants you to accept either the target, or the source.   As long as the case selectors do not conflict, there should be no problem to simply accept both changes.

For example, a base vi, with a case that handles 1, 2, 3 (and default).  And then the target adds the case for 4, and the source adds the case for 5.   LVMerge should simply be able to merge the cases so that the merged VI handles all cases 1, 2, 3, 4 and 5. 

At the moment, (LV2015 SP1) LVMerge doesn't do this...  I need to choose either for case 4 or case 5, but can't merge both.    And thus I have to discard either of the two cases, and rewrite them back in afterwards...   That's not the purpose of LVMerge...

NB:  These are cases where the two codes from target and source are not conflicting with eachother...   LVMerge should really be able to merge them automatically, and not even have to ask me to intervene!    But if it does, it should at least give me the option to merge both.

And this is a pretty common occurence!   For example: You have a master/slave pattern, where the slave interpretes the commands on bases of a command enum + case selector.  

[RavensFan]

I see a major problem with trying to implement this with respect to Enums.

If VI#1 has an enum A, B, C, D, it has numerical values of 1, 2, 3, 4.

If VI#2 has an enum A, B, C, X, Y  it has numerical values of 1, 2, 3, 4, 5.

How do you merge these?  Both have a #4 with different text.  Which is the "duplicate" 4 and gets assigned a new number?  Does it become 5?  6?  If 5, what happens to the 5 in the other one.  How would LabVIEW sort all of this out?

[AnthonyDeVries]

I see what you mean.  

I would suggest that Labview first handles all non-conflicting changes.  So add Y = 5 to the enum list.   That's safe, because it doesn't disturb the other changes.  After that, it can allow the user to handle the conflict D=4 vs. X=4.

Instead of only allowing the user to either:

• Accept X=4, discard D=4
• Accept D=4, discard X=4

it should also allow to add the other value:

• Accept X=4, add D = next free value (6
• Accept D=4, add X = next free value.

That gives the user proper control, and allows accepting all the changes, so as to make a complete merge.  

Sure... when the enums changes numbers, that might brake things.  But that's why you should always make the enum a typedef... In that case, changes in value or order of the enums items should be transparent, and not break anything.

I would think that people that use LVMerge will always typedef their enums, and use enum constants to evaluate their enums.  Otherwise a big program is impossible to maintain anyway... 

Besides that, the only thing I can images that would break the merge, is when the program relies on certain enums to be in order, so that it can iterate through them.   But such an important constraint should be documented... In that case, it is really the job of the person one who merges, to check that after the merge that the order of the enum is still correct.  It's not really necessary that LVmerge allows that option within the merge.  (That's too much extra functionality for too little use cases) 

Anyway, the person performing the merge would be aware that he has possibly messed up the order, when he accepted to renumber one of the enums.  That's one situation where human intervertion after the merge is always necessary.   

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.