Revision Control Best Practices

[COIEngineer]

I'm using Labview 14 Full Version, and trying to set up a system for a test-lab computer.

I currently want to have our released versions of testing programs easily accessible to everyone while I have working development versions for my own use. I'm currently using TortoiseSVN for rev control, but am open to very inexpensive (<$50) other options.

The following are my current thoughts on how to implement this. Is this a bad practice?

1) Use SVN Repository for everything

2) Checkout the project to a "Released Directory", create desktop shortcuts to this directory.

3) Checkout the project to a separate working directory. Work as usual, committing revisions as usual.

4) When ready to release an updated version, use the "SVN Update" on the "Released Directory"

I think this would work, but it seems cumbersome and/or dangerous. Is it better to just do a save as copy - full tree every time, or is there some better way to solve this?

Thank you!

[GerdW]

Hi Engineer,

the most appropriate solution would be to provide executables for your testbenches!

Then you implement a simple update mechanism in your software to have the executable check for new versions available. I store the most recent version of the exe on your (internal) server…

[mnml_mouse]

but how can I restore the attached file CMM-200.v?

[Dennis_Knutson]

mnml,

Do not hijack an unrelated thread.

[Hooovahh · Accepted solution]

Running a VI from source should only ever be done by developers, not by an end user.  Okay maybe that is a little harsh since I don't adhear to that all the time.  But the point is a build EXE is how a released version of code should be ran.  Make an EXE, increment the version, make an installer which includes the EXE and has a version as well.  Install the installer on the test PC updating the existing EXE if there is one.

If I were writing VB code I wouldn't install the full development environment on every PC it was going to be ran on, and then show users how to open the source and run it.  I would build an EXE and distribute that to the users.  This helps lock down released versions and feature sets.  You know you have a version 1.0.0 of an EXE, and you know the features of it.  When you commit your source to SVN you can leave a comment saying this code was used to make build 1.0.0 and now you can roll back your source at any time to the source used to make that EXE.

[COIEngineer · Accepted solution]

---

@Hooovahh wrote:

Running a VI from source should only ever be done by developers, not by an end user.  Okay maybe that is a little harsh since I don't adhear to that all the time.  But the point is a build EXE is how a released version of code should be ran.  Make an EXE, increment the version, make an installer which includes the EXE and has a version as well.  Install the installer on the test PC updating the existing EXE if there is one.

If I were writing VB code I wouldn't install the full development environment on every PC it was going to be ran on, and then show users how to open the source and run it.  I would build an EXE and distribute that to the users.  This helps lock down released versions and feature sets.  You know you have a version 1.0.0 of an EXE, and you know the features of it.  When you commit your source to SVN you can leave a comment saying this code was used to make build 1.0.0 and now you can roll back your source at any time to the source used to make that EXE.

---

Thank you. That is a helpful way of thinking about it. 

[billko]

---

@Hooovahh wrote:

Running a VI from source should only ever be done by developers, not by an end user.  Okay maybe that is a little harsh since I don't adhear to that all the time.  But the point is a build EXE is how a released version of code should be ran.  Make an EXE, increment the version, make an installer which includes the EXE and has a version as well.  Install the installer on the test PC updating the existing EXE if there is one.

If I were writing VB code I wouldn't install the full development environment on every PC it was going to be ran on, and then show users how to open the source and run it.  I would build an EXE and distribute that to the users.  This helps lock down released versions and feature sets.  You know you have a version 1.0.0 of an EXE, and you know the features of it.  When you commit your source to SVN you can leave a comment saying this code was used to make build 1.0.0 and now you can roll back your source at any time to the source used to make that EXE.

---

In theory, I agree.  In practice, it's whatever the customer wants.  I've seen cases where it's in the requirements that it be run in the dev environment.  Sometimes the customer wants direct access to the source code.  😕

If I am in control of the requirements, I definitely favor the executable.

[ElectroLund]

I'm not yet a LabVIEW dev.  I'm coming from the LabWindows world, but trying to get my mental ducks in a row before committing to a switch.

One of those ducks is how to think about revision control in LV.  I'm a software guy, so the thought of not doing CVS freaks me out.

Are all the "source" files of a LV project ASCII-based? It would appear that vi filetypes are binary, which is unfortunate, given that a CVS only works efficiently on ASCII files. 

[cordm]

VIs are binary files, so they do not profit from the existing tooling for text files. But you can still use them with source control. The most important tip is to separate compiled code from VIs, otherwise you will clutter your history with changes due to recompiled sub VIs and inflate the repository size. You do not really need to worry about efficiency - there are people with gigabytes of project storage... 

Nowadays, most people seem to use git. There is a user group on here with a lot of helpful documents: https://forums.ni.com/t5/Git-User-Group/gh-p/grp-2368

[ElectroLund]

thanks, cordm.  Same rule applies in software -- avoid any compiled code in the repo!

The big obvious problem with binary files in a CVS is the lack of merging changes.  But then I guess a visual design file just doesn't lend itself to multi-author changes.

I'll check out your Git group!