10-16-2012 10:40 AM
@SteveChandler wrote:
@User002 wrote:
@SteveChandler wrote:
GIT and Mercurial do not do VI Package Management. They do not have LabVIEW pallette editors or dependency checking. They do not connect to the tools network and there are no VI Package Configurations.
Man am I happy about the simplicity of a clean vanilla LabVIEW installation with only GIT and Mercurial as a code distribution and version control back end.
Less is more.
Br,
/Roger
Again, VIPM has nothing to do with source control. You absolutely do not need to use it. I use it because it simplifies package management and because there are a lot of tools out there that you need VIPM to install.
VIPM is for stuff that goes into vi.lib. It is code that a developer will use and not edit. It is not meant for distributing a project to another development machine that will be working on that project. If you do not create "reuse code" then you do not need the package builder. Regardless of that, VIPM is the tool that you need to install reuse code such as OpenG. It is to LabVIEW what RPM is to Linux.
Not so fast. It is a developer tool mainly. Such as GIT.
But without the external-tool stigma crappyness attached to it.
The "RPM" for LabVIEW is a MSI/Setup.exe.
Br,
/Roger
10-16-2012 10:41 AM - edited 10-16-2012 10:43 AM
You should check out this webcast on code reuse http://zone.ni.com/wv/app/doc/p/id/wv-2085. There are problems that cannot be solved with source control although I give you five stars for using it and five more for your enthusiasm!! You are a mile ahead of many people who think that source control is an added layer of complexity when, as you already know, it is to simplify problems.
[Edit: And even though there might be some bugs in VIPM, it is the only tool that I know of that solves the problem that it is intended to solve]
10-16-2012 10:49 AM
@User002 wrote:
Yes, it is called a branch.
No, a branch means you are dealing with a different set of code. This is exactly what you do NOT want with a reuse library.
10-16-2012 10:50 AM
@SteveChandler wrote:
You should check out this webcast on code reuse http://zone.ni.com/wv/app/doc/p/id/wv-2085. There are problems that cannot be solved with source control although I give you five stars for using it and five more for your enthusiasm!! You are a mile ahead of many people who think that source control is an added layer of complexity when, as you already know, it is to simplify problems.
Thanks! I appreciate it.
Yes, GIT works great for me for both LV and text based languages. I'm using tortoisegit as a windows shell extention.
A good VCS simplifies a lot in my daily developer life, specially with good commit-comments to the changes, etc, branching, merges (text based), tags, releases, etc.
I think the LV world is very much immature compared to world-class text based software houses in terms of SW dev techniques.
Br,
/Roger
10-16-2012 10:53 AM
@crossrulz wrote:
@User002 wrote:
Yes, it is called a branch.No, a branch means you are dealing with a different set of code. This is exactly what you do NOT want with a reuse library.
A branch usually shares the common ancestor, at least in decent VCS's(in GIT creating a new branch adds about 20kb). It is not a complete different code. A fork would be more or like a complete disconnect.
Br,
/Roger
10-16-2012 10:59 AM
@User002 wrote:
I think the LV world is very much immature compared to world-class text based software houses in terms of SW dev techniques.
Depends what you consider "world-class". At my previous company, we (the LabVIEW developers) used a lot more SW dev techniques than the actual software and VHDL people. And this is for code going into space (rockets, satellites, Mars rovers, etc).
I would say most of the LabVIEW developers are using the same or equivalent techniques as the majority of normal software developers.
10-16-2012 11:03 AM - edited 10-16-2012 11:06 AM
@crossrulz wrote:
Depends what you consider "world-class". At my previous company, we (the LabVIEW developers) used a lot more SW dev techniques than the actual software and VHDL people. And this is for code going into space (rockets, satellites, Mars rovers, etc).
I would say most of the LabVIEW developers are using the same or equivalent techniques as the majority of normal software developers.
Since you have been working with rocket science you are hereby disqualified from speaking about the common LV coding practises.
The classic WTF when opening up LV code "someone else" have written: http://thedailywtf.com/Articles/Labview-Spaghetti.aspx
If you'd think such coders know anything about SW dev practises and teqniques. You'd be wrong!
Br,
/Roger
10-16-2012 11:14 AM
That is NOT the normal. That was written a long time ago. LabVIEW and its ecosystem has evolved A LOT since then. Also, what you linked to is a typical beginner code. But you know what, I've seen even worse in C++. I will concede that it is easier to get bad code to work in LabVIEW. But as a whole, the LabVIEW ecosystem is just as evolved as any other language's ecosystem.
10-16-2012 11:16 AM
RogerIsaksson wrote:A branch usually shares the common ancestor, at least in decent VCS's(in GIT creating a new branch adds about 20kb). It is not a complete different code. A fork would be more or like a complete disconnect.
Br,
/Roger
While it is not completely different, it is different enough to not be the same. You have project A and project B using some subVI. You fix a bug in the subVI that affects project A but project B saw the bug as a feature. You can solve this by including a copy of the subVI in both projects. VIPM helps with this kind of situation.
I just realized that we are completely hijacking some poor guys thread. I just wanted to reemphasize that VIPM has nothing whatsoever to do with source control and JKI has never claimed it to be any kind of replacement. Arguing that GIT is better than VIPM is like arguing that phones are better than cars. You can call someone or drive over and talk to them. Which is better really depends. But phones and cars have very different purposes.
10-16-2012 11:21 AM
Kudos for the rocket scientist comment
But if you want to see real spaghetti code take a look over here.