I noticed a number of people asking about revision control, specifically, SVN. Quick to defend my most favorite piece of software ever, Git, I whipped up a document describing how teams can implement it in their C, C++, or LabVIEW programs:
Anyone who wishes to help edit it, feel free to request permission (if there isn’t a link PM me your email to add, make sure you have a Google Docs account). Also, anyone who wants to help figure out how to fit it into FIRSTwiki somehow is also welcome (see my footer).
I want to focus on the philosophy of revision control, how to best use it during the fast paced action of the build season, how to make it work with LabVIEW, and a description of the best workflow (who pulls and pushes from/to whom - I still don’t have this one figured out exactly).
Suggestions, from people new to Git especially, would be much appreciated!
I noticed it has a bianaray build for Leopard (mac OS 10.5), even in PowerPC (which I didn’t know there were even Leopard builds for), but it doesn’t seem to have a build for Tiger (mac OS 10.4).
Will it operate only on 10.5, or will it function on both?
I don’t have any firsthand experience using Git on Mac OS X, but I know it does work, though I can’t name any specific OS. The people I know, who I collaborate with, that use Git on Mac OS X use MacPorts. I don’t know how well the OS X packages linked to on the Git homepage work at all. Let me know if you find something that works.
I’m going to cross-post this document to the volunteers I work with in the Pittsburgh area, and also link to it in a similarly-themed post I plan to make to Delphi. Thank you for writing this!
I’m curious if anyone has tried it with LV files yet. I’ve been meaning to make myself try it out, but haven’t found the time. Since git it primarily command line driven, it should be pretty easy to produce a LV SCC plugin – they are called providers in LV. Perhaps Santa will let me tinker with it over the next few days.
But again, any experiences anyone has will assist.
The “software engineering tools” of LabView only appear to be available in the “Professional Development System” which as of the 2009 season teams do not get (the “Full Development System” which appears to be one step down), and iirc you said there are no plans to provide teams with these tools (as I understand the Professional version also includes tools to generate stand-alone executables which teams don’t need). I did read up on the documentation on how to use those features, and added that to the document anyways, in case anyone had that version or if teams are ever able to use it in the future.
Git can’t merge two different VIs without creating a conflict, so merging is almost impossible given time constraints. It also appears that simply opening and saving the file changes the data (maybe it saves a timestamp or something, I don’t know). Doing any truly distributed effort is hard to do.
It appears teams will be getting the professional version this year according to this document from Joe Ross, detailing the Labview changes from 330’s Beta Test.
Yep, teams will be getting at least the SCC features of the pro version. The most beneficial feature of that is an integrated check-out and check-in locking. The VI files do contain some time stamps and even pointers in them, so they are not meant to be diffed outside of the LV editor. The LV editor does a graph comparison of the source and displays the objects and describes the differences. As of 8.6, I don’t think merge is there or is a good implementation.
As for distributed development, Engineering firms usually seem to have ten or fewer programmers working on the same project in LV. Bigger than that and you need to isolate them into subgroups a bit. Even with that, and you need some coordination. Cowboys are a pain in the neck on any project, but can really cause issues on a LV project – one of the tradeoffs of a graphical language.
Ah thanks for the updates, I briefly searched around but couldn’t find anything, and consider this was written and posted about a year ago. I’ll do some more research when I get my hands on the software then (unless that is already possible somehow?).
What our team did was develop it in Sub-VI’s. With SVN, we could at LEAST have older versions with time stamps in case there were problems with a newer build. It worked out pretty well.
If I get any time tomorrow, I’d like to play with getting LabVIEW to work with Git. I know Austin has written something, but I want to see how it plays with 8.6
So far it seems to work ok with version control, though I can’t seem to get the merge to do anything. It’ll open lvmerge, but the changes don’t see to be, well, merged. Not sure if that is lvmerge’s problem, or my lack of knowledge in Git.
Haven’t gotten lvdiff to work yet, not sure what is wrong with it.
Edit: Apparently, lvdiff wants arguments… Investigating…
Edit 2: Can’t figure out the diff, all it says is that they differ
If it is saying “binary files differ” it probably is still using the default diff program. Try my updated document, I think I made a bad assumption the first time, and I took out the extra download, it looks like LabView has a native diff/compare tool. Also try running “git config --list” to see all the applied configuration options.
Additionally, if when “merging” it is actually only taking one version (%A) and discarding/ignoring the conflicting version (%B) and the common base (%O), that would indicate it isn’t actually merging anything, since Git expects the merged result to be written to the local copy with changes (the %A). I could just be getting the argument order mixed up, but I don’t think so.
Yeah, I don’t know. I took a look at the arguments for it, but it seemed fine. When I do the merging using the LabVIEW executable, it just pops up with a little error cluster indicator saying all is well, and then closes. Not sure if that is nominal or not, there’s very little documentation on some things.
“git diff” either does nothing or prints out a paragraph length of empty space to the terminal.
Still get the same thing for merging. The little error dialog does spend some time being open, but I can’t find anything else open. When I did it, it didn’t seem to merge anything, just use the last commit out of the two branches I merged.
The merge.labview.recursive was my fault. What difference does it make being set vs. not set? Maybe LVMerge is getting executed, just badly.
Try prepending “echo” to the driver too, to see exactly what it is calling. It should be giving LVMerge a set of three temporary files to evaluate then write back. Maybe you want to try it by hand too, check the NI documents I linked to.
Google suggests that no one has ever tried using Git and LabView together before, or, everyone else has just gotten it right the first time. In any event it doesn’t appear to be a heavily used feature of LabVIEW.
Maybe it is also the case that you have to use \ or / instead of a single \ (though it looks like you have tried that).
It doesn’t appear to, though I’ll try doing it directly from the command line to see if LVMerge is doing anything at all…
If I do a echo for the diff, I get two files (first the current, then I guess the previous commit) and then some sort of number (timestamp?).
Echo’ing the merge, does have 4 files, though their names aren’t really specific (.merge_file_a03232).
Hehe. I guess everyone use Perforce or nothing. :\
In the absence, of LVCompare, I’ve almost got lvdiff working, though the LabVIEW vi they use is currently yelling at me for missing some file (though it is very vague on that as well).
Looking a Perforce, seems you can get a free 2-user copy. Exciting. sigh Guess it just wasn’t meant to be?
In any event it doesn’t appear to be a heavily used feature of LabVIEW.