C and LabView version control with Git

[Nibbles]

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:

Revision Control with Git for FRC Teams

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!

[kamocat]

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?

[Nibbles]

Originally Posted by kamocat

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.

[fixermark]

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!

[Greg McKaskle]

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.

Greg McKaskle

[Nibbles]

Originally Posted by Greg McKaskle

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.

Greg McKaskle

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.

[Vikesrock]

Originally Posted by Nibbles

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).

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.

[Greg McKaskle]

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.

Greg McKaskle

[Nibbles]

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?).

[Nadav Zingerman]

Originally Posted by Greg McKaskle

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.

Greg McKaskle

Are you saying LabVIEW's Merge tool isn't good enough?

[keehun]

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.

[Tanner]

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

-Tanner

[Nibbles]

Is the 2010 software already available? I assumed it isn't but I think I should ask.

[Tanner]

Originally Posted by Nibbles

Is the 2010 software already available? I assumed it isn't but I think I should ask.

Not yet. Our team is assisting another with the beta.

-Tanner

[Tanner]

Had some trouble getting the .gitconfig to like the labview merge driver path. Had to change it to this:

driver = 'C:/Program Files/National Instruments/Shared/LabVIEW Merge/LVMerge.exe' 'C:/Program Files/National Instruments/LabVIEW 8.6/LabVIEW.exe' %O %B %A %A

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

-Tanner