ASTDan Posted January 8, 2010 Report Share Posted January 8, 2010 (edited) 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 January 8, 2010 by ASTDan Quote Link to comment
Tanner Posted January 8, 2010 Author Report Share Posted January 8, 2010 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 Quote Link to comment
asbo Posted January 8, 2010 Report Share Posted January 8, 2010 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" Quote Link to comment
ASTDan Posted January 8, 2010 Report Share Posted January 8, 2010 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. Quote Link to comment
Tanner Posted January 8, 2010 Author Report Share Posted January 8, 2010 (edited) 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 January 8, 2010 by Tanner Quote Link to comment
asbo Posted May 10, 2010 Report Share Posted May 10, 2010 Necromancing this "tread" Tanner, did you ever find a satisfactory solution? Did you abandon git altogether? Quote Link to comment
Ton Plomp Posted May 11, 2010 Report Share Posted May 11, 2010 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 1 Quote Link to comment
Tanner Posted May 18, 2010 Author Report Share Posted May 18, 2010 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 Quote Link to comment
Popular Post Tassos Posted August 10, 2011 Popular Post Report Share Posted August 10, 2011 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/t5/LabVIEW/LabVIEW-with-Git/td-p/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 3 Quote Link to comment
SteveChandler Posted August 10, 2011 Report Share Posted August 10, 2011 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> Quote Link to comment
asbo Posted August 10, 2011 Report Share Posted August 10, 2011 <iframe src="http://www.youtube.com/embed/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... Quote Link to comment
Jordan Kuehn Posted August 10, 2011 Report Share Posted August 10, 2011 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. Quote Link to comment
Yair Posted August 10, 2011 Report Share Posted August 10, 2011 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. Quote Link to comment
SteveChandler Posted August 10, 2011 Report Share Posted August 10, 2011 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. 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.