Collaborative progamming and version controll

[ruben.carvalho]

Is there any solution to collaborative programming at Labview in the most recent versions, with controll version. I would like to have the capabilitie for instance, of merge diferent versions of the same project by different people and observe the diferences between them. I know that in the past versions there is a tool called Source Code Control  & Configuration Management. But i can't find anything similar at the moment.

Thanks.

[udka]

What version of labview you are refering to?

- I am sure it still exists in all versions of labview.

-for more info : http://www.ni.com/white-paper/4114/en/ and https://decibel.ni.com/content/docs/DOC-2936

[Bob_Schor]

Because of the graphical nature of LabVIEW, comparing and "merging" different versions of the same VI is an "interesting" proposition.  LabVIEW can compare two VIs using its Compare tool, so you can see the difference, but if you want to make changes (as opposed to replacing VI1 with VI2, or VI2 with VI1), you largely have to do that, yourself, "by hand".

In some versions of LabVIEW, you can try linking the routine that LabVIEW uses for its Compare tool to your Version Control System.  However, the (relative) difficulty of doing compares and merges with Graphical Code makes code management, and following good practices in using your Source Control routines (like frequent Commits, with good documentation of the changes, to allow you to go back to the "last good version").  Also, if you have multiple people working on the same code, coordinating the efforts of the team is particularly important.

Bob Schor

[Sam_Sharp]

The last time I worked on a large project with a team, we split up the project tasks into lvlibs and each developer worked on their own lvlib. The lvlibs were added to the project and we usually put some stub VIs on the top-level diagram which would get populated as the developers worked on their code modules.

LabVIEW gets very messy if you have multiple people working on the same VI (merging is almost impossible, but it is possible to diff using the lvdiff utility that comes with LabVIEW) so for any instances where this was the case (e.g. core/shared code, top-level VIs, the lv project) you had to acquire a lock to edit the files. Also be aware to make sure that you don't accidentally merge the .lvproj file (as it's text) as it's quite likely it will get corrupted.

If you are good with your module design so you have low coupling between modules, it is possible to work on projects effectively as a team.

[Stuart.Parkinson]

The last collaborative project I worked on we used an external souce control system and each person checked out the whole project read-only, and then checked out the specific vis they were working on for edit. The SC system locked files so that only one person could have them checked out for edit at one time. At frequent intervals, everyone would do an 'update' to refresh the latest versions of all the vis in the project. This worked very well.

You just need to watch the project file itself. Normally having this read-only is not a problem, but if you need to create new vis (or move them or anything else that affects the project structure) then it is necessary to get the project file for edit, add the new vis, and then check it back in.

Good coordination amongst the team as to who is working on what is essential for this to work well. In general we never had need to diff and merge because of the way we organisied the work.