LabVIEW Developers Feature Brainstorming

[gmart]

I'd like some help from the LabVIEW community with a LabVIEW feature that has been largely overlooked (I figured the title of the post would garner more attention than the typical "Here's a new feature" subject). I'm curious as to the user base of the LabVIEW VI Revision History feature (File>>VI Properties>>Revision History). Specifically, if you use the feature and if you do, for what reasons. If you don't, why not? Does the feature set not match your needs? In addition, do you use source control instead of or in addition to VI Revision History? For those who use VI Revision History and source control, what additional functionality would you like to see? In general, what are good/bad points of this feature?

I understand that government accounts require versioning of code. Is VI Revision History the only way to achieve compliance? Is source control revision not sufficient? What would make the process of versioning code/traceability easier?

Thank you for your input.

[tst]

I would rather it stayed. When I have a project which evolves over time it is good to be able from some point to describe changes made to complex VIs. Then, if something goes wrong, I can look at the revision history and see what the latest changes were and know if I need to fix something or maybe even revert to an older version. If I do revert to the older version, the history will tell me which changes I need to code again.

Due to our current development method, I don't use SCC, so I can't comment on that.

[gmart]

Thank you for your feedback. The development process you described is how you would use source control software to track your changes. I'm interested in what you do to revert to an older version of a VI. I would guess that you have an ad hoc source control process so all that is missing is an actual software package that manages your code.

[Albert.Geven]

Hi Gmart

At the moment I don't use the history a lot, because either I forget it or I have already another change.
We used to have the popup for history enabled but almost nobody liked it. Because it popped up always also for changes as recompile and cosmetic changes.
If and only if it popped up when something changed in the blockdiagram (not cosmetic) but functional.
Look in the compare function to see what options are important.

Also I would like an option for automatic saving history comment, like recompiled from version x.x.x to version y.y.y when apropriate.

Last but the most intriguing is the save the real history in a kind of logfile so that I can go back version to version, building a real version control system in labview.
Make this automatic, coupled to some existing source safe (not source safe from MS) but an open source version control system.
We had too maniy problems with visual source safe.

[gmart]

Albert,

Thank you for your response. I didn't understand what you meant by this:

"Last but the most intriguing is the save the real history in a kind of logfile so that I can go back version to version, building a real version control system in labview.
Make this automatic, coupled to some existing source safe (not source safe from MS) but an open source version control system.
We had too maniy problems with visual source safe."

Do you mean you want the VI Revision History logged to a file? What do you mean by coupling to an existing source control system?

[Albert.Geven]

Hi gmart

Indeed the option to have a kind of each version saved instead of only comment.

One option is to save each version with the vi version somewhere in the filename, but the problem is the loading if the version number is part of the filename.
Easier is to rename the original vi with its original version number attached and save the new version under the original name.
Incredibly slow for .llb files but these are not easy to use in a modern system, only ok for distribution.

It is a kind af poor mans easy to understand version system. And with the disksize now available it is acceptable.
But connecting this to a version control system is saving each new version as you save. Maybe this is already what happens but I'm not using it yet.
If modern labview uses this approach please tell me.

At the moment we use an external version control system that saves a complete version when it is modified but we are not using it after each change.

In fact an automatic save of edited by: "userxyz" and changed "xynn" nodes could also help to identify big changes by a user without having to type anything.
I like to type in changes when I changed more than a few nodes but now it is always or never add comment and a margin of say 10..20..50 ? nodes could be set to identify significant changes from insignificant ones. It is a volume approach but important changes could receive more change points.

[MattH]

With the source control expansion already included (and hopefully supporting more clients in the future), I don't see the need for revision history.

I use CVS and keep a Change Log for the project. I can retreive dates prior to changes made via referencing the change log.

[Bob_Y.]

There are times when I make several changes to a VI and then check it back in to source code control.  If I correctly do my job of documenting these changes in the revision history, I can use that to remind me what all changed when I go to check it back in.  If I have several VIS checked out for several days or a week to fix a problem, it is sometimes difficult to remember what changes were made to what VIs.  That is where the revision history comes in handy. 

Version control change documentation would be something like:

Fixed Major Bug with I/O - Loop was too slow for proper analog input and caused a timeout.

The Revision History would be 10 to 15 entries with everything that was tried and what finally was done to speed up the loop.   It has a much higher level of detail since there is an entry every time I save (again, if I correctly do my job of documenting these changes).

Would I miss it, probably.  Could I live without it, sure; I can take these notes elsewhere.

Thanks,
Bob Young

[tst]

---

gmart wrote:
Thank you for your feedback. The development process you described is how you would use source control software to track your changes. I'm interested in what you do to revert to an older version of a VI. I would guess that you have an ad hoc source control process so all that is missing is an actual software package that manages your code.

---

When I work on a project I normally create a daily copy of the relevant directories. If necessary, I can then review those VIs or simply use the old directory. Using the revision history for the complex or top level VIs allows to see when certain changes were implemented and that way I can know which directory to go to.

[GuenterMueller]

I see the need  for the VI Revision History as we frequently develop VIs for our customers - and the customers do not use SCC. Without the VI Revision History I would be totally blind when visiting the customer. So I prefer to maintain and improve the VI Revision History.