LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
hongcc1

Option to Disable VI Revision History for Source Code Control (git)

Status: New

The idea is the same as Separate Compiled Code From Source File. When using external source code control (SCC) software like git, the user may want to track only the source code content changes. However, when every time saving the VI, the VI Revision History will be incremented. This reflects the change in VI attribute / VI properties, even though the other contents are the same.

hongcc1_0-1611440443410.png

 

This makes the commit log like git hard to trace the real change in the source code content from a high level. When using the compare VI tool, this attribute change will be one of the highlighted difference, which is quite distracting & confusing such as below:

hongcc1_0-1611439309083.png

 

I suggest this option can be disabled at the level of VI, project, or environment like the option of Seperate Compiled Code from VI. Hope it would be accepted 🙂

4 Comments
crossrulz
Knight of NI

Somewhat related (declined) idea: Enable modification of VI history via property nodes 

 

I still hold the opinion that the revision history should just be completely removed from VIs.  But as AristosQueue already mentioned in the linked thread: "R&D will not be spending any time on VI history. The only reason it hasn't been removed is that removing it would take time, and there's no compelling reason to remove it."


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
hongcc1
Member

Hi @crossrulz, thanks for sharing the idea link. Didn't notice the post when doing the search. I never use the revision history feature since SCC covers most of the needs and do it better. And I believe the SCC tool will be continuing more prevalent and easier to use. Hope my 'compromised' idea by disabling it could be accepted by R&D.

bodypillow
Member

"'... The only reason it hasn't been removed is that removing it would take time, and there's no compelling reason to remove it.'"

 

Translation: "The LVdiff tool, only available with the expensive pro licenses, is the only way to discern whether a completely irrelevant change like the rev# alone has caused the VI binary to change.  If we removed that absurd behavior, external source control use would at least be sort of feasible without the pro license."

AristosQueue (NI)
NI Employee (retired)

bodypillow: That's the first time I've heard of anyone raising that as an issue. Do you commonly have a problem with developers changing the revision number and creating diff issues for your team? If this is a real problem, that could constitute the first "compelling reason" to remove it (if we found multiple customers in the same bind), but if this is just a hypothetical, I would stand by my previous statement. Please clarify.

 

Also, I'm not understanding why removing rev# would have any impact utility of other diff tools. There are plenty of settings on a VI that are not reflected in a diagram image for which only LabVIEW can provide differentiation (the entire VI Properties dialog, for example). Can you further explain what makes rev# special?