Using LabVIEW with Git

[Tanner]

Hi all,

I'm in the FIRST robotics community, and next year we're getting a copy of LabVIEW 8.6 Pro which has the a few programs included for use in source control.

Anywho, we're interested in using some sort of source control to keep track of our code and allow simultaneous development with several programmers. A quick Google search shows little or few relevant results of using LabVIEW with Git.

I'm wondering if any of ya'll, LabView users, have ever used Git for tracking your code? If so, how have you accomplished it? If not, what have you used that is free to use?

Any information would be helpful.

Thanks

-Tanner

[crelf]

No experience with Git, but I'd use SVN with locking.

[ASTDan]

I really like TortoiseSVN

Here is a presentation on an introduction to TortoiiseSVN

http://decibel.ni.com/content/docs/DOC-7811

[Tanner]

Is there a tutorial or something of the sort for setting up SVN for LabVIEW?

The main reason I would like Git is because it is distributed so fellow programmers could work on it at home, without being connected to the main Git server. Plus it has nice branching capabilities.

Thanks

-Tanner

[ASTDan]

Is there a tutorial or something of the sort for setting up SVN for LabVIEW?

The main reason I would like Git is because it is distributed so fellow programmers could work on it at home, without being connected to the main Git server. Plus it has nice branching capabilities.

Thanks

-Tanner

To my knowledge you have to get a 3rd party tool to integrate SVN directly into LabVIEW.

The 2 I am aware of are

JKI TortiseSVN for LabVIEW

PushOK

I use Tortoise SVN just in the Windows Explorer environment.

A programmer could work on their code not having access to the repository (server) with TortoiseSVN however to commit and update code you would have to be connected. I don't know how you could manage your code if you weren't connected to a repository.

You don't have to have your repository on a server. You can have it on your local hard drive or on the web.

Branching in my opinion is easy in TortoiseSVN.

I have never tried Git so I don't know the merits of it.

Edited January 5, 2010 by ASTDan

[Tanner]

To my knowledge you have to get a 3rd party tool to integrate SVN directly into LabVIEW.

The 2 I am aware of are

JKI TortiseSVN for LabVIEW

PushOK

I use Tortoise SVN just in the Windows Explorer environment.

Thanks - I'll have a look at those.

A programmer could work on their code not having access to the repository (server) with TortoiseSVN however to commit and update code you would have to be connected. I don't know how you could manage your code if you weren't connected to a repository.

You don't have to have your repository on a server. You can have it on your local hard drive or on the web.

Well, the benefits of having the entire source distributed is that the user can do commits without the server (versus doing all a nights work in one big commit the next day - bit harder to narrow down bugs). Having the source distributed also means I have the entire history of the repository so I can do diffs, logs, and reverts without the server. Quite nice.

-Tanner

[ASTDan]

Thanks - I'll have a look at those.

Well, the benefits of having the entire source distributed is that the user can do commits without the server (versus doing all a nights work in one big commit the next day - bit harder to narrow down bugs). Having the source distributed also means I have the entire history of the repository so I can do diffs, logs, and reverts without the server. Quite nice.

-Tanner

Are you saying it takes a whole day to commit . Why couldn't you commit at night?

How do you know what the other folks on you team are doing if you aren't connected to the server? If programmer A and programmer B work on the same piece of code how do they get each others changes? Are you using a lock method i.e. nobody can check out your code until you check it back in?

From what I briefly read about GIT each person has their own repository. What I don't understand is how that works in a multi-programmer environment. How do you know what version of the software is right one? If you have 5 developers you have 5 valid repositories of the code? Who's is valid? That sounds like a nightmare to manage. Is there something I am missing?

[asbo]

How do you know what the other folks on you team are doing if you aren't connected to the server? If programmer A and programmer B work on the same piece of code how do they get each others changes? Are you using a lock method i.e. nobody can check out your code until you check it back in?

From what I briefly read about GIT each person has their own repository. What I don't understand is how that works in a multi-programmer environment. How do you know what version of the software is right one? If you have 5 developers you have 5 valid repositories of the code? Who's is valid? That sounds like a nightmare to manage. Is there something I am missing?

These are the right questions to be asking - they're definitely problems OP is going to run into using Git. Since each developer has his own stand-alone repository, it would be very difficult to work concurrently on code; you don't know if anyone else is working on the same code until you've both sync'd with the master or pull'd one another's code. Either way, I think it would add a lot of unnecessary logistical problems that can easily avoided with existing, proven solutions. It's a really, really awesome system for files you can merge (a.k.a., text) but I think that (and some people on LAVA disagree) that using SCC with a locking paradigm is the right way to develop LabVIEW code.

[Tanner]

Are you saying it takes a whole day to commit . Why couldn't you commit at night?

How do you know what the other folks on you team are doing if you aren't connected to the server? If programmer A and programmer B work on the same piece of code how do they get each others changes? Are you using a lock method i.e. nobody can check out your code until you check it back in?

From what I briefly read about GIT each person has their own repository. What I don't understand is how that works in a multi-programmer environment. How do you know what version of the software is right one? If you have 5 developers you have 5 valid repositories of the code? Who's is valid? That sounds like a nightmare to manage. Is there something I am missing?

No I'm saying that when the programmers aren't in contact with the server, Git could still commit locally while SVN would complain (unless something's changed since last time I used it).

Well, you don't. Though I'm guessing this is where the merge capability comes in. I'm not sure if Git has this lock method.

Well, there would be a central server and there would be a repository on each developer's computer. Then after a developer has made a commit, they can push the code to the central server.

These are the right questions to be asking - they're definitely problems OP is going to run into using Git. Since each developer has his own stand-alone repository, it would be very difficult to work concurrently on code; you don't know if anyone else is working on the same code until you've both sync'd with the master or pull'd one another's code. Either way, I think it would add a lot of unnecessary logistical problems that can easily avoided with existing, proven solutions. It's a really, really awesome system for files you can merge (a.k.a., text) but I think that (and some people on LAVA disagree) that using SCC with a locking paradigm is the right way to develop LabVIEW code.

I'm going out a limb guessing that everything would work fine as long as developers did not work on the same vi or something of the such? It also seems that this locking method is recommended? to prevent merging two vi's (because the way of merging isn't the best?)?

Basically what I'm trying to understand is why locking is preferred? Is it just because it prevents having to merge?

Thanks

-Tanner

[asbo]

Though I'm guessing this is where the merge capability comes in. I'm not sure if Git has this lock method.

You can't just merge binary files (which VIs are, obviously) and while LV provides a merge tool, you'll usually spend more time sorting out the merge than just taking one version's changes and implementing it in the other by hand. As for locking, not really - the argument is made (for SVN, as well) that since locks are really only advisory, you should use "proper" forms of communication and collaboration. I don't agree - I think it's awesome to have an SCC which has a built-in mechanism for this situation.

I'm going out a limb guessing that everything would work fine as long as developers did not work on the same vi or something of the such? It also seems that this locking method is recommended? to prevent merging two vi's (because the way of merging isn't the best?)?

Basically what I'm trying to understand is why locking is preferred? Is it just because it prevents having to merge?

In theory, yes, that'd work. The reason I prefer locking is because it's very valuable to have the repository "know" when a developer is working on a particular object so that information can be distributed without any extra effort on the developer's part. I can't imagine having to e-mail around my multi-developer team everytime I was going to update a bunch of VIs - I only see that as useless overhead. Ideally, you never have developers working on the same extra area at once, but exceptions can (and always will) surface - if it's no skin off your back, why not use a system. I can see why you'd want to be able to make commits without necessarily pushing code, though; it's can be handy to have instantaneous versioning as you develop. There's no stigma involved because you're not actually committing WIP code to a public resource.

So it looks like your decision weighs down to the flexibility of local version control versus a mechanism to control code concurrency.

[Daklu]

I second the suggestion to use a single development line with locking. Merging branches in Labview is a real pain. Suppose two people change different VIs that are independent of each other, but each change required several common sub VIs to be recompiled. When trying to merge the branches all those sub VIs are flagged as needing to be merged, even though they have not changed functionality. I've had hundreds of VIs flagged when a co-working recompiled the project--not fun. Also, Labview doesn't offer a way to merge .lvproj, .lvlib, or .lvclass files. Simultaneous edits of those files can be very difficult to resolve, especially the .lvclass files. Often you have to throw out one branch and recreate the changes after the other branch has been merged.

IMO, the single best thing you can do to avoid conflicting changes is to design your application to be as modular as possible and assign owners to each module. (i.e. RF Receiver, Propulsion, Vision, Chainsaw Controller, etc.) Create the rule that nobody except the owner can change a module's VIs. Define the interfaces (input and output VIs) for each module that allows it to send and receive whatever information it needs. Libraries (.lvlib or .lvclass) are very helpful for this kind of modular programming as you can set the interface VIs to be public and everything else to be private.

If you set your application up right you'll save yourself tons of time down the road when crunch time comes.

[jcarmody]

...Chainsaw Controller...

[Yair]

I'm going out a limb guessing that everything would work fine as long as developers did not work on the same vi or something of the such?

Not necessarily. As others have alluded, there are times when LV will recompile a VI even if you haven't changed it (such as when you change a typedef it uses or the connector pane of a subVI). One way of working around this is setting the tread read-only VIs as locked switch in the LV options, but this would ideally require an SCC system which integrates with LV. As I mentioned in the NI thread, there is documentation about this, so you should read that.

[crelf]

IMO, the single best thing you can do to avoid conflicting changes is to design your application to be as modular as possible and assign owners to each module. (i.e. RF Receiver, Propulsion, Vision, Chainsaw Controller, etc.) Create the rule that nobody except the owner can change a module's VIs. Define the interfaces (input and output VIs) for each module that allows it to send and receive whatever information it needs. Libraries (.lvlib or .lvclass) are very helpful for this kind of modular programming as you can set the interface VIs to be public and everything else to be private.

That's a good plan, but there may be exceptions (eg: working on a system at 3am and you need to fix a small bug). That said, if that was the case, I'd do it, but then follow up with the "owner" as soon as practical.

One way of working around this is setting the tread read-only VIs as locked switch in the LV options...

Totally true - this should be the default setting IMHO. If you agree with me, vote it up over here!

[asbo]

One way of working around this is setting the tread read-only VIs as locked switch in the LV options ...

I didn't know about this!

[Ton Plomp]

But could we get back to the original question?

If Tanner can get Git to work with the LabVIEW Diff and Merge tools, that would be awesome.

I will be disconnected from my private SCC server for a few weeks and with Git I can still commit on a normal basis and re-sync when I get back.

So getting this to work will be a benefit for us all.

Ton

[Yair]

vote it up over here!

I find it amusing that you copied it with the spelling mistake, but I guess I'm too easily amused.

[asbo]

I find it amusing that you copied it with the spelling mistake, but I guess I'm too easily amused.

I had to go double check the Options panel to make sure I was thinking of 'tread' in the right way.

[Ton Plomp]

Trying to keep this topic on topic.

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

Ton

[crelf]

I find it amusing that you copied it with the spelling mistake, but I guess I'm too easily amused.

Yes Yair, you are

[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 January 7, 2010 by crelf
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 January 7, 2010 by crelf
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