LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Using git as Source Code Control

I found this KB article describing how to use Source Code Control in CVI.

The article says that Perforce, Subversion and Microsoft Team Foundation Server 2010 have been tested with CVI.

 

Has someone successfully integrated git as SCC tool in CVI?

Is there some special configuration needed?

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 1 of 10
(6,495 Views)

Hi Vix,

GIT is a version control system that can be used to revision and track any type of document. It was actually originally designed to work with C / C++ files. While, there is not specific integration for GIT into CVI you will still be able to use it to its full potential through some 3rd party client or command-line interface. You can find a lot of existing resources on how to use GIT outside of NI.

In terms of the support of GIT, you found the KB which talks about which versions that integrate with LabWindows CVI, and GIT is not part of that, thus NI won't officially support it in case of any trouble.

You can post a product suggestion to integrate GIT support in CVI!

I hope this helps!

Bye,

 

Licia

Message 2 of 10
(6,328 Views)

Thank you.

I've just added a new message in the LabWindows/CVI Idea Exchange Forum.

 

Feel free to support the idea, if you think it can be useful.

 

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 3 of 10
(6,325 Views)

Agreed.  And for anyone who does not use source control now, don't wait for integration. Download it now. There is even a basic Git GUI there if you are not ready for the command line. It can be run strictly locally (of course you do have off-site backups, right?) and is fast, light and valuable even for a single developer working alone.

 

I should have started using it years sooner than I did (although my CVI use started way before Git!)

Message 4 of 10
(6,320 Views)

Getting started with Git...

 

What files do you commit to source control? I'm sure .c, .h, .uir, .prj and .cws, but do you also rev control all the stuff in the cvibuild.[project name] \Debug directory? All the .obj, .res, etc. files?

 

That is, everything, or just specific files that would allow you to rebuild the project at a given point, letting the CVI IDE pull everything else together?

 

0 Kudos
Message 5 of 10
(5,353 Views)

You should commit only files necessay to rebuild the project.

Don't commit neither the cvibuild.[project name] folder, not the .exe files.

To better handle the uir files, follow this suggestion and commit the tui files too.

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
Message 6 of 10
(5,348 Views)

I probably wouldn't put the .cws files under source code control either, unless they reference multiple projects, and you would like that share that grouping. This is because the content of .cws files consists primarily of settings that are typically not shared across developers.

 

You can use this table to help you decide whether you should share those settings or not.

 

Luis

0 Kudos
Message 7 of 10
(5,216 Views)

Hi Luis,

I agree to your suggestion only partially.

Even if the .cws reference one project only, it includes the cds file used to buid the installer.

I think this a mess, and if I'm right some years ago I contributed to a thread on the forum discussing some disadvantages of the cws/prj/cds strcutre of CVI (but I can't find the thread anymore).

Based on my experience, cws should not tracked by git, but it's better to do it, because NI included some essential configuration in a file that should not have been used for this purpose...

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 8 of 10
(5,213 Views)

You have a good point concerning the .cds file, but couldn't you work around that by keeping just the .cds file itself in source code control? Any other developers that share the project could easily also add the shared .cds file to their own workspace (Build>>Distributions>>Manage Distributions>>Add...) and from that point on, they would be able to build the same distribution as everyone else.

0 Kudos
Message 9 of 10
(5,195 Views)

From the "CVI point of view" this is true, but it's a little bit strange for developers who are used to a source control system.

As a matter of fact, every time you checkout a branch, the "dirty" .cws file is left in the working folder (if you don't clean it) and so you don't need to relink the cds. But if you checkout from scratch (of after a clean), you have to relink it.

Moreover, what happens if two branches doesn't share the same cds and the cws is not deleted from the working dir?

 

I think that NI should improve a lot the project layout and file format, so that working with a source control system is easy as with other programming languages (both for CVI and LabVIEW).

Sadly, but from my point of view, time for "workarounds" is over (compared with other programming languages which improved a lot in the last few years to simplify the development activity).

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 10 of 10
(5,157 Views)