Jump to content

Using LabVIEW with Git


Recommended Posts

One of the advantages of decentralized storage is the following workscheme:

-Production at 'the office' where a SCC server resides

-You go onsite to a client

-You find some minor bugs

-You change the production code

-You can however not commit the changes because the SCC server is not available to you

-So you save everything, make some notes

-The next day (or week) you come back at the ofice, take your notes and commit the code

My understanding is that with GIT, you can always commit your code.

Ton

I am curious how other people handle this. You bring up a good point if you are in a remote location without access to the server how do you handle this? That being said 90% of development time you would have access to the server, so is having this feature worth the management issue? Personally since I am a single developer I just have my repositories on my local hard drive. So I can always commit.

I guess it comes down to (like most everything else) is how you and your organization work and want manage the issue of SCC. If you spend a lot of time without access to a server and your development team was very small, maybe this model would be more desirable.

Edited by ASTDan
Link to comment

In response to the "do it online" post (I can't figure out to get it to post with multiquote), using a server would be harder in my situation. Since we mainly work/program at school - an environment where we have no internet, and no cell phone signal most of the time - having the server there (i.e. - located on the main development station or another computer there) would be a lot easier than using the internet. If I used the internet, that means I would have to bring the code to the school - something I am liable to forget. Yeah, we could have developer stations I could take home, but our main one is a dual-screen desktop which is nicer to work with.

I am curious how other people handle this. You bring up a good point if you are in a remote location without access to the server how do you handle this? That being said 90% of development time you would have access to the server, so is having this feature worth the management issue? Personally since I am a single developer I just have my repositories on my local hard drive. So I can always commit.

Depends what situation you are in. I haven't had much experience with Git, but I'm guessing the answer would be merging. How exactly the workflow breaks down, I don't know - could probably research it.

-Tanner

Link to comment

Well, LVMerge opens, shows the error window, and closes, but there doesn't seem to be a active merge between the two files. It's not doing a merge or saving it. And yes I have it now. -Tanner

Are you passing relative paths? Referencing the help file on SCC/LVMerge I made that mistake at first as well (I was getting error code 7 out of NI_FileType.lvlib:Get File Type.vi). Using absolute paths worked fine, though.

C:\Program Files\National Instruments\Shared\LabVIEW Merge>LVMerge.exe "C:\Program Files\National Instruments\Shared\LabVIEW Merge\base.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\theirs.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\mine.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\output.vi"

Link to comment

In response to the "do it online" post (I can't figure out to get it to post with multiquote), using a server would be harder in my situation. Since we mainly work/program at school - an environment where we have no internet, and no cell phone signal most of the time - having the server there (i.e. - located on the main development station or another computer there) would be a lot easier than using the internet. If I used the internet, that means I would have to bring the code to the school - something I am liable to forget. Yeah, we could have developer stations I could take home, but our main one is a dual-screen desktop which is nicer to work with.

I see now why a distributed SCC would be interesting to you. :lightbulb:

Link to comment

Are you passing relative paths? Referencing the help file on SCC/LVMerge I made that mistake at first as well (I was getting error code 7 out of NI_FileType.lvlib:Get File Type.vi). Using absolute paths worked fine, though.

I think it is using relative paths now that you mention it. I'm trying to figure out where exactly Git gets/puts the files...

I see now why a distributed SCC would be interesting to you. :lightbulb:

Yeah. No internet stinks. Although it is a eye-opener to how much we depend on it nowadays. :\

-Tanner

Edited by Tanner
Link to comment
  • 4 months later...

Necromancing this "tread" :P

Tanner, did you ever find a satisfactory solution? Did you abandon git altogether?

I think I know what the issue was with GIT Diff.

I stumbled upon the same issues with Mercurial where the remote file was copied into the system temp directory. The LVDiff utility from Sourceforge tries to load both VIs in the same app.space. I edited the diff VI to rename the file in the temp directory. Some more details are on the Mercurial wiki page.

Ton

  • Like 1
Link to comment

Necromancing this "tread" :P

Tanner, did you ever find a satisfactory solution? Did you abandon git altogether?

Yeah, sorry, busy with the robots and recently finals.

No, I never did find a satisfactory solution. I didn't have time to mess with Git more and using SVN wouldn't be very satisfactory with how things are set up here (at least it wouldn't be as useful as Git would be).

-Tanner

Link to comment
  • 1 year later...

Heya all!

I posted a solution to the diff problem in the ni.com discussion forum. you can find it here:

http://forums.ni.com.../1047455/page/3

Merging seems to work fine with me, just by following the google doc that Ton Plomp suggested.

Hope you find it useful

Cool! I will look at this later. I have used GIT a lot but do not have any experience using it with LabVIEW.

There are many advantages to GIT or any decentralized SCC system. I do development at work on my laptop. I can VPN to the corporate network when I am working from home but sometimes I like to work in places where there is no internet connection. I have experienced horrible connections in hotels for example.

Does everyone know how GIT originated? It was written by Linus Torvalds - creator of Linux. He gave a really good presentation on GIT to the developers at Google who use Subversion a lot. He talks about his hatred of CVS and how he prefers "tarballs and patches" over that. He tells people that if they like SVN they should just leave. The developers of SVN say that it is "CVS done right". Linus claims that if this is their starting point there is nowhere to go because "you can not do CVS right"

GIT earned the reputation of being very difficult to use. It is heavily command line based (Look who developed it). But there are a lot of higher level tools now and you no longer need to use the command line. I think I recall seeing something that tunnels GIT over a VSS interface so that you can use it from the LabVIEW IDE.

<iframe src="http://www.youtube.com/embed/4XpnKHJAok8" allowfullscreen="" frameborder="0" height="349" width="425"></iframe>

Link to comment

It doesn't really address the fundamental problem that is the source of all the others listed previously; VIs are binary files and all these tools are made for text files.

Exactly. I haven't used either Git or Mercurial, but I have seen Thorvald's session a couple of years ago and I remember that he emphasized that the reason Git is so much better is because it does merging properly and effortlessly, something which is a problem in LV.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.