LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Revision Control Best Practices

Solved!
Go to solution

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!

0 Kudos
Message 1 of 12
(4,384 Views)

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…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 12
(4,343 Views)

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

0 Kudos
Message 3 of 12
(4,332 Views)
mnml,

Do not hijack an unrelated thread.
0 Kudos
Message 4 of 12
(4,310 Views)
Solution
Accepted by COIEngineer

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.

Message 5 of 12
(4,235 Views)
Solution
Accepted by COIEngineer

@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. 

0 Kudos
Message 6 of 12
(4,216 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 12
(4,186 Views)

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. 

0 Kudos
Message 8 of 12
(1,653 Views)

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

Message 9 of 12
(1,643 Views)

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!

0 Kudos
Message 10 of 12
(1,623 Views)