How to use Source Code Control for Large Application?

Question

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

Answer 1

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