38 replies to this topic

[Tanner]

Trying to keep this topic on topic.

Here is a note on using LabVIEW and GIT, it references a Google Docs.

Ton

That's the exact topic that me and my friends are discussing this in (though abit without the deep knowledge of LabVIEW). It's a scare topic of using Git.

:\

-Tanner

[asbo]

That's the exact topic that me and my friends are discussing this in (though abit without the deep knowledge of LabVIEW). It's a scare topic of using Git.

It looks like you're heading in the right direction - still no luck in setting up LVMerge properly?

Edited by crelf, 07 January 2010 - 11:22 PM.
Removed reference to LabVIEW 2010 beta feature

[Tanner]

It looks like you're heading in the right direction - still no luck in setting up LVMerge properly?

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

Edited by crelf, 07 January 2010 - 11:22 PM.
Removed reference to LabVIEW 2010 beta feature

[ASTDan]

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

IMHO merging code in LabVIEW is tricky.

I also don't really understand the fear of a centralized server to manage a repository. The distributed model in my opinion would be a nightmare to manage.

I think it is interesting that the author of this article posted this on Google docs. Which is a centralized server for sharing data.

I think in your case having a server to manage would be a pain. I think putting your repository on something like google docs or using a subversion (or GIT) web hosting service would make sense. You don't have to worry about the server going down or losing your data. You just need to have internet access.

I also want to point out it is a good idea to use a Revision control system for other files that are not source code files (i.e. drawings, block diagrams, specs, manuals, etc).

[Ton Plomp]

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

[ASTDan]

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, 08 January 2010 - 02:27 PM.

[Tanner]

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

[asbo]

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"

[ASTDan]

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.

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

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.

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

-Tanner

Edited by Tanner, 08 January 2010 - 07:33 PM.

[asbo]

Necromancing this "tread"

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

[Ton Plomp]

Necromancing this "tread"

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

[Tanner]

Necromancing this "tread"

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

[Tassos]

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

[SteveChandler]

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.c...ed/4XpnKHJAok8" allowfullscreen="" frameborder="0" height="349" width="425"></iframe>

[asbo]

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

Crap, why does this have to be an hour long? I do want to watch it, though...

[Jordan Kuehn]

You can also take a look into Mercurial. That is the SCC we are currently using and is distributed. 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.

[Yair]

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.

[SteveChandler]

Another big plus for GIT is that the integrity of the repository is cryptographically verified. You can not change the history of or corrupt the repository without GIT noticing. With others you only notice your repository is corrupt when you get an old version of your code and find that your VIs will not open.