C and LabView version control with Git
 

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!

Re: C and LabView version control with Git
 

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?

Re: C and LabView version control with Git
 

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.

Re: C and LabView version control with Git
 

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!

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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.

Re: C and LabView version control with Git
 

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.

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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.

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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

-Tanner

Re: C and LabView version control with Git
 

Had some trouble getting the .gitconfig to like the labview merge driver path. Had to change it to this:
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

Re: C and LabView version control with Git
 

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.

Re: C and LabView version control with Git
 

I'll try that and see if it'll work.

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.

-Tanner

Re: C and LabView version control with Git
 

For some reason, I don't have a LVCompare.

Had to change the binary line to this for it to execute:
And I could not get the merge.labview.driver line to run. Git didn't like it for some reason.

If I have this in my .gitconfig for the diff,
"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.

-Tanner

Re: C and LabView version control with Git
 

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

Re: C and LabView version control with Git
 

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?

-Tanner

Re: C and LabView version control with Git
 

Ooh I forgot, a diff program is supplied with the file path, 40-character SHA1 hash, and file mode, first the old, then the new (of all places, this is documented in git(1)). If the diff program doesn't recognize those parameters you need a shell wrapper script that will only pass the first and fourth arguments, or pass them with the correct command line switches/order/etc.

For merge, you could try it by hand, see if it writes a new file. If you make one change to a base file, save as A, and then a different one to the base file, save as B, then merge base, A, and B out to C.

It could also be that the merge tool doesn't overwrite existing files, in that case you need a shell script that can rename the %A file to something else, perhaps like "mv %A %A.old; LVMerge $O $B %A.old %A; rm %A.old" or something like that (I don't know if that would work the way I think it would, especially on Windows).

Re: C and LabView version control with Git
 

Ah. I read about that, but I guess I didn't think about it for the 7 arguments just cause it didn't seem relevant.

I was thinking about doing that, but after playing with lvdiff for and trying to figure out a solution, I got tired. It's worth a shot though.

Would be a odd possibility, but again something worth trying. It appears Git can do shell scripts so, the gist of what you wrote should work.

I wonder if any of the LabVIEW devs know anything about using Git and all the such.

-Tanner

Re: C and LabView version control with Git
 

If by devs, you mean developers, I'm in that camp, and I've asked around and nobody has yet used Git for any project. If you LabVIEW users, then the LV forums would be a good place to ask.

It sounds like you are having issues getting the LV diff and merge tools to integrate into Git. I was actually going to look at it from the opposite direction, and use the command line interface to Git so that it could be invoked for check out, in, etc. I won't get to look at it until next weekend at the earliest.

Greg McKaskle

Re: C and LabView version control with Git
 

Interesting. I'll have to see if I can find any LabVIEW users who have used Git. Hopefully someone has, otherwise we're breaking new ground.

Opposite direction? I think that is what we're trying to do, but it just doesn't appear to work. It'd be nice for you to look at it, though I'll see if I can find anyone else has done this before.

Thanks
-Tanner

Re: C and LabView version control with Git
 

As Greg McKaskle pointed out earlier you can implement "providers" that let you (if I understand correctly) run simple commands like commit, checkout a revision/file, etc, many IDEs have something similar. I didn't bring it up because I can't find much documentation on it... but that would be another great thing to tackle after merging gets working. It looks like it would be under Tools, Source Control, Configure Source Control. There are a few quirks that might not be anticipated, like Git's index if you are trying to commit files (whereas other version control systems use "add" to introduce new files only and "commit" to scan for changes in already added files then commit everything they find, "git add" is used for both new content and changed content, it adds those changes to an "index", and "git commit" simply turns that index/stage into a new commit, making the process very flexible and fast). In general it seems like there is no problem using something like LabView with a distributed version control system, any more than any other problem that a graphical language presents.

Re: C and LabView version control with Git
 

I posted on a few LabVIEW forums and it seems that Git isn't widely used. SVN seems to be the free tool of choice, which kinda stinks for having a distributed system.

-Tanner

Re: C and LabView version control with Git
 

I got LVDiff and LVMerge to work with Mercurial, which isn't too different from Git. I am in the process of writing a white paper on the matter. For now you might want to try my modified version of LVDiff (That's the beauty of GPL), available here. It takes only two arguments, the paths to the VIs to be diffed.

Re: C and LabView version control with Git
 

I'll have to take a look at that. Though right now I'm trying to get the LVMerge working (which is pretty neat when it does work). No I haven't gotten it to work yet, but just doing it from the command line is nifty.

-Tanner

Re: C and LabView version control with Git
 

I can't get it to even write a file. The dialog shows "Error 7" (meaning File does not exist) unless I supply the absolute file path, when I do that it shows success, but still fails to write a file anyways. When I use the UI front end it works as expected and generates an unsaved file which you have to save by hand. I would step through the program to see why it isn't writing the file supplied on the command line, but the source is encrypted, so I'm at a loss.

It looks like writing a source control provider involves more work than just supplying commands to run, so that's out of the question for the short term.

In other news I updated the document with pretty graphs illustrating various workflows that would be useful for a team, as well as adding a section on Java/NetBeans, and expanding the section for WindRiver Workbench (which is just Eclipse, which in turn was written as a Java IDE, I don't see why they don't just use Eclipse, but that's another question for another thread).

Re: C and LabView version control with Git
 

I have LVmerge working with tortisegit after following this tutorial for tortisesvn
Link

Can someone explain to me what lvdiff is needed for? Does lvmerge include lvdiff?

Re: C and LabView version control with Git
 

There is a 3rd party diff implementation called LVDiff which uses the existing VIs provided with the Development system to perform a diff. It has a bit of overhead, all you really need is to run a supplied VI with the two files and LabView will launch the diff tool (I have a .vi that can do this correctly parsing the command line arguments, I'll attach it when I get the chance). In the "2009" edition of the documentation (but not 8.6) there is a pre-provided LVCompare.exe file that does the same thing, compiled into a binary. LVMerge.exe is the official merge tool and is provided with our 8.6 version, but it doesn't seem to be writing over the correct file, instead returning a successful result, but not writing it out, thus taking one file as the merged result entirely ignoring the other... the only explanation I can come up with is a software bug.

I have played around with TortoiseGit (forked from TortoiseSVN), you can get two changes in two separate files to merge into one? I can get as far as calling LVMerge with the (as I understand) correct arguments (or using the merge under Tools->Source Control iirc).

Re: C and LabView version control with Git
 

Yes, after following the instructions in my previous post, merging seems to work.

For a test, I created a simple VI that uses a loop with a shift register to increment a number. I immediately created a new branch and switched to it. In that branch, I replaced the shift register with a feedback node. I committed and checked out the master branch. In the master branch, I added a time delay to make the counter run slower. I committed master. I then did a merge from the second branch into master and it worked just like in the tutorial. The resulting file has a feedback node and a time delay.

I've also tried making conflicting changes to the robot code. It made me choose which version of the conflict I wanted to keep, and honored my choice.

I really like this.