LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

How to use Source Code Control for Large Application?

Highlighted
Hi, All!
 
I would like to collect knowledge about "best practice" examples for using Source Code Control and project organization for relative large application (let's say approx 1000 SubVIs).
 
Tools used:
LabVIEW 8.0
CVS Server
PushOK CVS Proxy Client
WinCVS
 
With LabVIEW 8 we can organize large project pretty well. This described in article Managing Large Applications with the LabVIEW Project.
I have read this article too: Using Source Control Software with LabVIEW In this Article Source Safe used, but with PushOK all looks nearby the same and works (some tricks for compare function are required).
Example. Two developers working together on same project. Internally project is modular, so one developer will work with module "Analysis", and another one with "Configuration" without interferences. These modules placed into Subfolders as shown in example above.
 
 
Scenario 1:
 
Developer A started with modification of module "Analysis". Some files checked out. He would like to add some SubVIs here. So, he must also perform check out for the project file (*.lvproj), otherwise he cannot add anything into project structure.
 
Developer B at the same time would like to add some new functions into module "Configuration". He also needed to check out project file, but this file already checked out by Developer A (and locked). So, he must wait until lvproj file will be checked in. Another way is mark *.lvproj files as text files in PushOK, but then one of developers will get conflict message by checking in and then merging will be necessary. This situation will coming very often, because in most cases *.lvproj file will be checked out all the time.
 
Question: Which practice is better for such situation? Is Libraries better than folder for large project?
 
 
Scenario 2:
 
Developer C joined to the team. First, he must get complete project code for starting (or may be at least code of one Library, which assigned to him).
 
Question: How it can be done within LabVIEW IDE? Or WinCVS (or other SCC UI) should be used for initial checkout?
 
 
Scenario 3:
 
Developer D is responcible for Build. Developers A,B,C have added lot of files into modules "Analysis", Configuration" and "FileIO". For building he need to get complete code. If our project splitted into folders, he should get latest *.lvproj first, then newly added SubVIs will appear in Project Explorer, then he should expand tree, select all SubVIs and get latest versions for all. If Project organized in Libraries, he must do the same for each library, isn't?.
 
Question: Is this "normal way", or WinCVS should be used for this way? In WinCVS its possible with two mouseclicks, but I prefer to get all code from CVS within LabVIEW IDE recursively...
 
 
That was a long post... So, if you already working with LabVIEW 8 with SCC used for large project, please post your knowledge here about project structure (Folders or Libraries) and best practices, its may be helpful and useful for all of us. Any examples/use cases/links etc are appreciated.
 
Thank you,
 
Andrey
 
0 Kudos
Message 1 of 4
(973 Views)
Regarding your scenarios:

1. Using your example, let's say both developers checked out version 3 of the project file. Assuming that there are only files under the directories in the example project, when Developer A checks in his version of the project, there will be new files in one section of the project separate from where Developer B is working. Developer B, notices that there is now a version 4 of the project. He needs to resolve the changes so will need to merge his changes to the latest version of project file. Since the project file is a text file, that is easy to do. Where an issue arrises is that after Developer B checks in his merged changes, there is a revision 5. When Developer A and B go to make another change, they get the latest version which will have the merged changes to the project file but not the referenced files from both Developer A and B. So when A opens version 5, he sees that he is missing the files that B checked in and visa versa. Here is where the developers will needs to manually use the source control client and, external to LabVIEW, get those new files.

Where libraries help with the above scenario is that the library is a separate file from the project so changes made to it outside of the project do not require the project to be modified. So this time, the developers are using a single project again which time time references two libraries. The developers check out the libraries, make changes to the libraries, and then check those changes in. So when each developer opens the project file, since it references the project file, the changes to the library will be reflected. There is still the issue of the new files not automatically coming down when the latest version of the library is obtained. Again, the developers will needs to manually use the source control client and, external to LabVIEW, get those new files. In general, you should take advantage of the the modularity that libraries provide.

2. As noted in the above scenario, there is no intrinsic mechanism to get all files referenced by a LabVIEW project. Files that are missing will be noted. The developer will then have to use the source control provider's IDE to get the initial contents of the project  (or library).

3. See above scenarios.
George M
National Instruments
Message 2 of 4
(957 Views)
Out of curiosity, how large an .lvproj file do you get with approximately 1000 subvi's? The Project Explorer seems to take a very long time to handle ours, it's a legacy app with about 3700 vis, and the .lvproj file is right at 2 MB. It takes a good 5 minutes on a P4-3.0 Ghz, Hyperthreading enabled, 3 GB ram, etc. etc. machine to open the .lvproj, expand the Build Specifications node, or edit a build spec. I'm guessing this is because the Project Explorer is reading / processing the entire .lvproj file for each of those actions.

I know ideally we'd have this monstrous program split into several libraries, each with their own .lvproj file. It's on the to-do list, but it's a non-trivial task.

This is in LabVIEW 8.0, we can't upgrade to 8.2 just yet because of some issues with generics, .Net, and the way 8.0 handles failures vs 8.2.


0 Kudos
Message 3 of 4
(878 Views)
I am assuming the files in the project are source controlled and source control is enabled in LabVIEW. In LabVIEW 8.2, there were some speed enhancements made to source control related to refreshing status of files as well as improving the time it takes to expand folders in a project if the folder contains a large amount of files. For now, I would suggest that if your project arrangement is very flat (i.e. not many folders), you might try to group your files in folders. This should reduce the number of items that needs to be displayed when the project loads.
George M
National Instruments
0 Kudos
Message 4 of 4
(869 Views)