Options for Revision History should affect Controls/TypeDefs

[Bob_Schor]

Whenever I configure LabVIEW for myself, I set the Option for Revision History to "Prompt for a comment when the VI is saved".  I've noticed, however, that when I update a TypeDef (.ctl), I am not prompted, and need to re-open the TypeDef, go into Properties, choose Revision History, and add it "manually".

While technically one could say that a TypeDef, being a .ctl, is not a "VI", the logic that would provide a Revision History option to encourage developers to document their changes should also apply (in my option) to TypeDefs, as well.  You can "disambiguate" the Option by changing "VI" to "VI or Control".  If there are other things (like Classes?) that might fall into this basket, this option should be similarly "expanded" to include them, as well.

Bob Schor

[Bob_Schor]

Just after posting this Idea (which I did after saving a TypeDef and having to "manually" enter a Revision Comment), I saved another TypeDef, and was prompted for a Revision!!!

What was the difference?  The first TypeDef had the generic NI Control icon, the second had an Icon that I designed.  I made a custom Icon for the first TypeDef, and when I saved it, I was prompted for a Revision.

So I'll amend my Idea to say "The Revision History Options should apply whether or not the Developer creates a Custom Icon or uses the Default".  [Is this "rule" documented anywhere?  I haven't looked for it, but certainly never heard about it, nor read about it in a number of notable LabVIEW books, including one Third Edition].

Bob Schor

[AristosQueue (NI)]

The Revision Control feature of LabVIEW is planned for obsolescence in the next few years. It is a hold over from a time when source code control systems were expensive and not easily supported by lone developers and small teams. Since we will likely be ending support for that feature in a couple years, I do not expect that we will do anything to enhance it in the nearer term.

[DavidBoyd]

AQ:

First I'd heard that this was on the roadmap.  Has this gotten much discussion with focus groups of users?

I recall prior discussions of how others use VI rev history where folks make multiple edits/saves to a checked-out VI, noting along the way, then rely on that VI history when committting to SCC and rolling up those notes into SCC history.  Is this pattern of use considered less than optimal?

Would appreciate a link to any place where this is presently under discussion (IOW, off this IE entry).

[AristosQueue (NI)]

> Has this gotten much discussion with focus groups of users?

We have discussed it with a few focus groups. This is only a MAY for us at this point. The feature is crufty old code that is getting in the way of other development, so it continues to be something that R&D would like to ditch. We don't want to have to refactor it to clean it up unless there is overwhelming use for it, and, honestly, there appears to be very little use of it, but those who do use it are emphatic about its value. It's a fairly classic niche feature: prized by few, unheard of by many, which leads to the question of the right thing to do to support it and the wider product.

There hasn't been a wholesale discussion on the forums with customers. We aren't going to kill it now. It's one of those things that we keep coding around in order to keep it alive, so there hasn't been direct pressure to kill it immediately. So it isn't disappearing any time soon, but it certainly isn't likely to get enhancements, per the request of the idea.

[AristosQueue (NI)]

> Is this pattern of use considered less than optimal?

I woud definitely consider it suboptimal myself. This is personal opinion on why that feature is junk.

a) It doesn't match development practice of any other programming language to have revision comments in file metadata.

b) It creates comments about the VI that are generally invisible. If they need to be noted, put them on the block diagram or context help, both far superior locations for comments about the diagram. If they need to be seen in revision histories, they should be in the SCC logs.

c) The "roll it into SCC later" doesn't really happen... there's no tooling for copy/pasting such comments, and changelists typically include many VIs, so comments on a single VI aren't really helpful. And it is hard to pair any given change in the VI with a particular SCC changelist.

d) Many things about VIs are hard to merge, but this feature is just makes merging VIs harder since two devs both made changes... which change log should win?

In short, it is a poor substitute for just checking your changes into SCC as you're working. Use a branch or git change compression if you just want one change recorded in your main trunk at the end of that period's work.

[DavidBoyd]

Thanks for the detailed replies and the well-expressed thoughts on workflow.  Sorry it took me several days to wander back here and read your comments.

Regarding point c), I recall that someone at NI created a private VI method with a name akin to "History.RevSince" which took a LV date/time value (I think it was an int32, that's how long ago this was), and returned history text forward from that date.  I suspect it was intended for use within the SCC tool VIs where a checkin could pre-fill comments logged since the last checkin, but never implemented.

I suppose I just need to get with the times and do daily checkins.

Dave

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined. 

[Bob_Schor]

I'd forgotten I'd posted this a year ago, only to have it declined.  I was thinking of re-posting it, not because I make such heavy use if Revison notations on my VIs and Controls (in fact, I've been doing less on VIs and have noticed a few places where "Add Comment when Saving" interfered with some new LabVIEW features), but was struck by the inconsistency between VIs and Controls.

Having now read AQ's very cogent comments, and having turned on "Require 40 characters in order to Commit" for Subversion (a practice I put in place 5-6 years ago), I have to say I agree that a Good VCS System is superior to (occasional) notations on individual VIs.