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?