LabVIEW
LabView VI in text format
@TimBlaisdell wrote:
I imagine that if I could save a VI as an XML file that contained every detail of every component on the screen (the location of every wire, every corner, every icon, etc., etc.)
Don't imagine anymore. NGX actually saves the gvi in an XML format.
@paul_cardinale wrote:
A VI should never be so large that it takes more than one person to support it.
While I think this is a good motto to live by, there are often time when two people will want to modify the same VI. Having more than one person support the VI isn't the problem, the problem might be if that one person goes on vacation with some uncommitted changes, then another person is forced to update that VI when they are away, and then when they come back a merge needs to happen. Still there are cases where a VI can be saved in XML but it is an experiment and undocumented.
I haven't seen if the XML in NXG helps merging. A merge only works well if the majority of the lines in the file are untouched after a change, and the format might be XML but still closed, and moving all objects one pixel over might cause every line to be changed. For this reason I think Lock, Commit works better for SCC in LabVIEW.
Alright maybe the word "often" wasn't enough of a qualifier. It has happened, and in my opinion it can happen easier if you don't have a lock commit paradigm.
@paul_cardinale wrote:
Then you have a problem with undisciplined staff (especially if that happens often).
You mean people in a rush to go on vacation, or travel for work, and forgetting that they even had something locked? It happens. If you have a team of 8 people, there's a good chance at least one of them is traveling or on vacation at any given time. On teams of this size I would say merging issues did happen around once a month, but were less frequent as time went on and individuals became more disciplined. Still the majority of the team in the situation I'm thinking of were younger, and less familiar with SCC. In these cases I would say no VI is so large that one person alone can't support it, but more than one member of the team should be able to support it independently.
@paul_cardinale wrote:
...than one member of the team should be able to support it independently.
When a person goes on vacation, it is the responsibility of that person, and also the responsibility of that person's manager to insure that the absence won't cause any problems. The failure of both those people to act appropriately cannot be corrected with technology. And where on Earth do you work where people are on vacation 1/8th of the time?
Agreed.
Re: 18th of the time
That would be me!
After 18 years plus the vacation days accumulate.
Ben
@paul_cardinale wrote:
@Hooovahh wrote:
Alright maybe the word "often" wasn't enough of a qualifier. It has happened, and in my opinion it can happen easier if you don't have a lock commit paradigm.
@paul_cardinale wrote:
Then you have a problem with undisciplined staff (especially if that happens often).
You mean people in a rush to go on vacation, or travel for work, and forgetting that they even had something locked? It happens. If you have a team of 8 people, there's a good chance at least one of them is traveling or on vacation at any given time. On teams of this size I would say merging issues did happen around once a month, but were less frequent as time went on and individuals became more disciplined. Still the majority of the team in the situation I'm thinking of were younger, and less familiar with SCC. In these cases I would say no VI is so large that one person alone can't support it, but more than one member of the team should be able to support it independently.
When a person goes on vacation, it is the responsibility of that person, and also the responsibility of that person's manager to insure that the absence won't cause any problems. The failure of both those people to act appropriately cannot be corrected with technology. And where on Earth do you work where people are on vacation 1/8th of the time?
Probably anywhere but the USA.
