[Tanner]

Ton Plomp, on 07 January 2010 - 01:39 PM, said:

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]

Tanner, on 07 January 2010 - 04:29 PM, said:

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?

This post has been edited by crelf: 07 January 2010 - 11:22 PM
Reason for edit: Removed reference to LabVIEW 2010 beta feature

[Tanner]

asbo, on 07 January 2010 - 04:57 PM, said:

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

This post has been edited by crelf: 07 January 2010 - 11:22 PM
Reason for edit: Removed reference to LabVIEW 2010 beta feature

[ASTDan]

Tanner, on 07 January 2010 - 11:08 PM, said:

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]

Ton Plomp, on 08 January 2010 - 06:45 AM, said:

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.

This post has been 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.

ASTDan, on 08 January 2010 - 09:09 AM, said:

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]

Tanner, on 07 January 2010 - 06:08 PM, said:

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]

Tanner, on 08 January 2010 - 04:14 PM, said:

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]

asbo, on 08 January 2010 - 11:28 AM, said:

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

ASTDan, on 08 January 2010 - 01:32 PM, said:

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

This post has been 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]

asbo, on 10 May 2010 - 10:38 PM, said:

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]

asbo, on 10 May 2010 - 03:38 PM, said:

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