06-28-2022 04:20 PM - edited 06-28-2022 04:21 PM
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
I guess probably soon now this should be taken offline, but I'm curious what you think should belong there? If not a VI's history, what history?
None? I think the argument is that the revision history should not be inside the VI at all. If you want to see the file's history, you look in SCC.
I can see the point, but I'm not sure what is really gained by removing it. 🤷
wiebe@CARYA wrote:For instance, if we wanted an XML based file it would be a lot easier if the binary file didn't need to coexist. Supporting n methods is typically not n times as hard, but more like x^n as hard (x will be >2 😊).
A new GUI system based on HTML5 or WPF (sigh) or whatever would be much harder to make if the old GUI system needs to coexist.
You could argue that a converter has to be made anyway. But keeping this separate will keep the both code bases smaller. Testing this functionality separate will also be easier.
Perhaps it could be executed better and/or done without breaking lots of other capabilities like it did, but that almost sounds like a pitch for NXG. 😜
06-28-2022 04:33 PM
@JimB. wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
I guess probably soon now this should be taken offline, but I'm curious what you think should belong there? If not a VI's history, what history?
None? I think the argument is that the revision history should not be inside the VI at all. If you want to see the file's history, you look in SCC.
I can see the point, but I'm not sure what is really gained by removing it.
Well this debate should be another thread, but I version a lot of source code, shell scripts, launchdaemon plist files, etc. Including contract negotiations and project management documents, I want that version with the document and not have to go back to the metadata in the git repository. So some folks feel the version information is useful and should be kept. And not send the final recipient of the code, document, diagram to some other possibly private repository. This is not "debatable" since the personal choice of where one prefers the documentation is not a universal truth any more than it is debatable whether one prefers chocolate or vanilla ice cream.
Scott (remember it takes all kinds to fill the freeways)
06-29-2022 02:56 AM
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
@crossrulz wrote:
@billko wrote:
@crossrulz wrote:
@BertMcMahan wrote:
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
I have personally been advocating for the removal of "ancient", rarely used features. First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.
I do see a possible benefit in removing "old" mutation code (pre-2009? 2012?). That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).
That's funny. I know I'm in the minority, but I put stuff in the revision notes all the time so when it comes to actually committing, I have notes for my commit.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
I guess probably soon now this should be taken offline,
Why? I hope I'm not being offensive, I don't feel offended.
@billko wrote:
, but I'm curious what you think should belong there? If not a VI's history, what history?
Nothing belongs there. It's history 😋! (<< To be sure: that is a joke.)
I'm not doubting that the purpose of the revision history is to store a history of revisions.
It's just that for me SCC does a far better job, so to me the revision history never had any use. In fact, even before I started using SCC, I didn't use the revision history.
06-29-2022 03:20 AM
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
@crossrulz wrote:
@billko wrote:
@crossrulz wrote:
@BertMcMahan wrote:
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
I have personally been advocating for the removal of "ancient", rarely used features. First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.
I do see a possible benefit in removing "old" mutation code (pre-2009? 2012?). That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).
That's funny. I know I'm in the minority, but I put stuff in the revision notes all the time so when it comes to actually committing, I have notes for my commit.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
I guess probably soon now this should be taken offline,
Why? I hope I'm not being offensive, I don't feel offended.
@billko wrote:
, but I'm curious what you think should belong there? If not a VI's history, what history?Nothing belongs there. It's history 😋! (<< To be sure: that is a joke.)
I'm not doubting that the purpose of the revision history is to store a history of revisions.
It's just that for me SCC does a far better job, so to me the revision history never had any use. In fact, even before I started using SCC, I didn't use the revision history.
Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space. I wasn't at all offended or anything. 🙂
06-29-2022 03:33 AM
@billko wrote:
Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space. I wasn't at all offended or anything.
We are off topic indeed... But I think I'm all done.
06-29-2022 08:54 AM
wiebe@CARYA wrote:
@billko wrote:
Oh, I simply meant we were veering off course from the original topic and thought we might want to just summarize our viewpoints so we don't take up too much space. I wasn't at all offended or anything.We are off topic indeed... But I think I'm all done.
Me, too. 🙂
07-18-2022 07:27 AM - edited 07-18-2022 07:28 AM
Anybody ever still using Database Access? 🤣
07-18-2022 07:35 AM
@Neil.Pate wrote:
Anybody
everstill using Database Access? 🤣
The only person I ever heard of using that feature (Ben) has now been retired for a few years. So that is another one of those features I would not mind being stripped out of LabVIEW.
07-18-2022 08:11 AM
@crossrulz wrote:
@Neil.Pate wrote:
Anybody
everstill using Database Access? 🤣
The only person I ever heard of using that feature (Ben) has now been retired for a few years. So that is another one of those features I would not mind being stripped out of LabVIEW.
Didn't someone complain recently (a week or two ago) that the database access had problems with binary data, or was that something else?
07-18-2022 09:37 AM - edited 07-18-2022 09:38 AM
@Neil.Pate wrote:
Anybody
everstill using Database Access? 🤣
I use it to freak out the newbies 😂.
The SubVI Node Setup (right above the Enable Database Access menu) does a great job at that too.