Repository for LabVIEW Project

[hobbs]

I'm working on a team of 5 to develop a relatively large software project spread across a PC, FPGA (R-Series card), cRIO, and an ARM board. Our last attempt this problem lead to a source control nightmare. We managed an svn repository using tortoisesvn. This became problematic because we couldn't edit any of the FPGA files without checking out the entire project. This lead to parallel projects being worked on and the eventual merging problems. I know that LV has a source control manager, but to my knowledge it requires you to have a relatively expensive source control manager. Does anyone have good ideas about how to manage a large, multi-fabric project without buying perforce?

[crelf]

We managed an svn repository using tortoisesvn. This became problematic because we couldn't edit any of the FPGA files without checking out the entire project. This lead to parallel projects being worked on and the eventual merging problems.

Sorry, but this doesn't sound like an issue with the SCC provider (SVN), but more like an issue with the way you were doing SCC.

What do you mean by "project"? The lvproj file or the whole project from the repository? You don't need to check out (in SVN terms it's "get lock", not "check out" - that's something different) to edit one part of it.

[Ton Plomp]

I'm working on a team of 5 to develop a relatively large software project spread across a PC, FPGA (R-Series card), cRIO, and an ARM board. Our last attempt this problem lead to a source control nightmare. We managed an svn repository using tortoisesvn. This became problematic because we couldn't edit any of the FPGA files without checking out the entire project. This lead to parallel projects being worked on and the eventual merging problems. I know that LV has a source control manager, but to my knowledge it requires you to have a relatively expensive source control manager. Does anyone have good ideas about how to manage a large, multi-fabric project without buying perforce?

You can use LabVIEW Profressional (not Base or Full) together with PushOK SVNSCC plugin. It's rather cheap (€30). Or JKIs TSVN interface which connects to SVN via TortoiseSVN.

Sorry, but this doesn't sound like an issue with the SCC provider (SVN), but more like an issue with the way you were doing SCC.

What do you mean by "project"? The lvproj file or the whole project from the repository? You don't need to check out (in SVN terms it's "get lock", not "check out" - that's something different) to edit one part of it.

Yes, please specify, you might need to uncheck the 'tread read-only files as locked' option. Also explore the 'Source Only' setting if you are using LabVIEW 2010.

Ton

[hobbs]

Sorry, I should have been more specific. To my knowledge, if an FPGA file is not opened through a LV project (as in lvproj file) it is not edited as an FPGA file. As a result, the project file must be check out and then updated every time you want to edit an FPGA file. Additionally, should two members need to edit FPGA files at the same time, the lvproj file will develop a conflict.

Sorry, but this doesn't sound like an issue with the SCC provider (SVN), but more like an issue with the way you were doing SCC.

What do you mean by "project"? The lvproj file or the whole project from the repository? You don't need to check out (in SVN terms it's "get lock", not "check out" - that's something different) to edit one part of it.

[SuperS_5]

I don't use FPGAs much personally, however, I do work on a very large project. We also use the project explorer to with tortoise SVN without much issue. Producing notes/internal documentation is very important however! Collisions with the lvprog file can be common, but, we don't edit that file manually much. We, therefore, simply overwrite the lvprog file with the modified version we require. I am not sure how much changes that you will actually make in the project explorer with FPGAs.

Using a LabVIEW version before 2010 can cause a lot of conflicts because of "recompiling," however, this is overcome by good documentation, and only committing the files that you actually changed. Every little while, we will commit a "recompile" with specifically only recompiled files, (after committing real changes) and enforce SVN "comments."

Mike