How to handle version changes? Strategies?

[cebailey]

From reading "Source Code Control and Group Development Practices in LabVIEW for Advanced Configuration Management Tasks", I gather that adding new VIs to a project is a big problem, and should be avoided:

"Adding or renaming files in a Project will alter the contents of the *.lvproj file, which requires checking it out and submitting a new revision to the SCC provider. Since these changes affect all developers using the *.lvproj file, it is inadvisable to make any modifications during development. If changes must be made, they should only be made by one user at a time, and all other developers should get the latest revision of this file as soon as changes are complete. However, there are alternatives when this is not possible.

Ideally, the framework for the application is determined before development, and placeholders already exist for all future code and functionality. However, changes are sometimes required that force modifications to the framework and therefore to the contents of the *.lvproj file. These modifications can potentially affect linkages throughout the application and should not be taken lightly. The recommended practice is to make these modifications offline and outside of development - all files should be checked in to the depot and locked to prevent checking out."

This sounds like an enormous problem! The document does propose using libraries as a way around this, but doesn't that mean the new source code is uncontrolled? Or is this less of a problem than it sounds like?

[Norbert_B]

---

cebailey wrote:
[...]

 I figured source control (which I have never worked with) had no place with a single programmer project. Should I reconsider?

[...] 

---

The answer to this question is definetly YES!

Using SCC helps in two different ways:

a) Securing Code from incorrect modifications. This option is mainly for multi-developer projects.

b) Version history. Each SCC provider supports a history for versions. So checking in the sources creates new versions and demands a comment (configurable, could be left out as well). So you can keep track of what changes were done and you can step back to an older version if the newer one is messed up due to whatever reason... This feature is very good even for single developer projects.

So all in all:

SCC  is mandatory if working with more than ONE developer, but recommended even for single developers.

You are correct that using SCC slows down the developement in the first instance because you have to know the tool and learn the processes needed or it.

But please imagine this situation:

You create an application with LV and, as a last step, remove all block diagrams. By accident, you save the VIs without BD over the original VIs in your project. BANG, if you have a bug in your application, you have to reimplement everything. You can loos several weeks due to such situations. Using SCC: Open the last version containing the BD, correct it and there you go, less than one minutes work (besides debugging).

If you are becoming more "natural" to the usage of SCC, you will loos nearly no time for this. The case you stated in your last post is correct: Because several files are changing in the project, you have to checkout them, alter them and check them back in. But remember that this will create a new version of the project, so making some false settings is corrected within seconds.......

hope this helps,

Norbert 

PS: You can use any SCC provider you like. But if you want to have a direct access to the provider from LV, the provider has to incorporate the MS Source Safe Interface.