04-24-2006 09:49 AM
04-24-2006 10:03 AM
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.
04-24-2006 11:12 AM
04-24-2006 12:37 PM
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.
04-24-2006 12:42 PM
04-24-2006 01:11 PM
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.
04-24-2006 01:43 PM
04-24-2006 01:57 PM
04-24-2006 02:15 PM
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.
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.
04-29-2006 11:51 AM