C and LabView version control with Git

[Nibbles]

Originally Posted by Tanner

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.

[Tanner]

Originally Posted by Nibbles

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.

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

Originally Posted by Nibbles

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.

-Tanner

[Tanner]

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

Had to change the binary line to this for it to execute:

git config --system merge.labview.recursive binary

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,

[diff "labview"]
	command = "C:/Program Files/meta-diff suite/lvdiff.exe"
	#command = 'C:/Users/Tanner/Desktop/FIRST 2010 Beta/lvcompare.sh'

"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

[Nibbles]

Originally Posted by Tanner

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

Had to change the binary line to this for it to execute:

git config --system merge.labview.recursive binary

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,

[diff "labview"]
	command = "C:/Program Files/meta-diff suite/lvdiff.exe"
	#command = 'C:/Users/Tanner/Desktop/FIRST 2010 Beta/lvcompare.sh'

"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

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

[Tanner]

Originally Posted by Nibbles

The merge.labview.recursive was my fault. What difference does it make being set vs. not set? Maybe LVMerge is getting executed, just badly.

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

Originally Posted by Nibbles

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.

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

Originally Posted by Nibbles

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.

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

[Nibbles]

Originally Posted by Tanner

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

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

[Tanner]

Originally Posted by Nibbles

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.

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.

Originally Posted by Nibbles

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.

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.

Originally Posted by Nibbles

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

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

[Greg McKaskle]

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

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

[Tanner]

Originally Posted by Greg McKaskle

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.

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.

Originally Posted by Greg McKaskle

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.

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

[Nibbles]

Originally Posted by Tanner

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

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.

[Tanner]

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

[Nadav Zingerman]

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.

[Tanner]

Originally Posted by Nadav Zingerman

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.

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

[Nibbles]

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

[sparrowkc]

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?