LabVIEW and SVN

[Morten_Pedersen]

Hi,

We are a company that develops test and measurement systems, with LabVIEW and TestStand. We are working in the latest and prior versions of the development systems.

We have in mind to change our existing source code control (SCC) to the following toolchain in the latest versions:

- Tigris Subversion Server on Linux (Tigris SVN)

- TortoiseSVN Client (to use SVN via file explore)

- PushOK SVN Client (to use SVN from the LV project explore)

Does anyone have some Pros. and Cons. Regarding this setup for company use with LabVIEW and TestStand?

I am looking forward to hear from you,

Best regards,

Morten Pedersen

[gt5816v]

Hi Morten,

We use TortoiseSVN here. It's painful with Labview. I've been looking into other SCC methods lately. If you check out files from SVN and work on them you should only save changes to files that have genuine modifications. Labview will prompt you to save all which will save your local machines file path and require all files to be re-committed to SVN. It's difficult though because changes to a global for example can cascade through so many VIs... One thing we've done to help with this is mapping a folder as a network drive on each of our developers machines and saving our work there. Then all files in the repository point to the "L" drive.

Curious if others have seen similar issues?

PushOK SVN is supported by Labview 8.0 and up I believe.

Hope this helps.

[tst]

Your problem is that LabVIEW saves the compiled code as part of the VI. When you do something that forces a recompile (like adding a control to a global VI or renaming an input on a subVI or even some things which you would think should have no effect on the caller), LabVIEW will ask you to save any VI which was changed. If you don't, it will recompile it the next time you load it and ask you again.

Personally, I don't have a problem with this. I prefer to know that all developers have the same version which was compiled properly. I just let TSVN pass as much of the code as needed through the network. That's what we have a reasonably high speed LAN for.

If you want to change it, however, you can go into the LabVIEW options and check the Do Not Save Automatic Changes check box. That will cause LabVIEW to stop asking you to save. In 8.x, this is found in the Misc. page. As I said, personally I prefer the other way.

I can't comment on using the PushOK plugin, but searching for "SVN", both here and in the LAVA forums, should return some results.

[Andy Peters]

"We use TortoiseSVN here. It's painful with Labview. I've been looking into other SCC methods lately. If you check out files from SVN and work on them you should only save changes to files that have genuine modifications. Labview will prompt you to save all which will save your

local machines file path and require all files to be re-committed to SVN. It's difficult though because changes to a global for example can cascade through so many VIs..."

That's not a Subversion problem, that's a LabView problem. You'll have the same issues with any revision-control system.

"One thing we've done to help with this is mapping a folder as a network drive on each of our developers machines and saving our work there. Then all files in the repository point to the "L" drive."

That's not a good use of a source-code control system.

-a

[gt5816v]

Andy,

Perhaps you could explain your comment further?

[gmart]

Certain changes to a VI will affect callers of that VI. Changing a global is one example. Another, is adding a control to the connector pane of a subVI. These kinds of changes are "automatic" changes. The next time the VI hierarchy is loaded, LabVIEW will automatically apply the change again to all callers. So, in theory you don't need to save the changes. The drawback is that the unsaved change will require the VIs to recompile everytime they are loaded so on a machine where the VIs aren't saved, there could be a performance hit. There is an option in Tools>>Options>>Environment named "Do not save automatic changes". It is tied to the option "Treat read-only VIs as locked". Here is the help info for the option:

"Does not prompt you to save any changes automatically implemented by LabVIEW. You do not need to save these changes because LabVIEW implements the changes each time the VI is loaded. Changes automatically implemented by LabVIEW include recompiling, converting from an older version, and updating type definitions or fonts. This checkbox is unchecked by default."

[PaulG.]

I've been in test development/R&D industry for over 20 years and have worked with a lot of different software, but I have never ran into anything more user-hostile than Tortoise/SVN. It might work very well with text files, but with LabVIEW it was an abomination.

[alkazaa]

---

@PaulG. wrote:

I've been in test development/R&D industry for over 20 years and have worked with a lot of different software, but I have never ran into anything more user-hostile than Tortoise/SVN. It might work very well with text files, but with LabVIEW it was an abomination.

---

Paul, what would you recommend then as a SCC solution for LabVIEW? Are you using any SCC with LV, then?

-Franz

[PaulG.]

Disclaimer: The opinions expressed in the following are strictly those of the guest and do not necessarily reflect viewpoints of this station, it's advertisers, station management, or my current or any previous employer.

I don't have a lot of experience with a lot of other source control software. I had no trouble at all with VSS but our IT guys didn't like it. My current employer is getting ready to implement VSS (I had nothing to do with it! Honest!). I heard NI uses Perforce. If NI can use Perforce it can probably work in just about any software development environment - but Perforce is pricey. SVN has worked in LV environments (many of the LAVA guys are crazy about it - or so they say) but I never saw a glimmer of hope using it in the 3-6 months I tried to use it. And if Perforce is "pricey" how much more "pricey" is "free" software that wastes dozens of manhours just trying to get the frackin' stuff to work?

[dan_u]

@Paul, could you elaborate a bit more what your problems with SVN were?

We're using SVN with Tortoise too. It works just fine. As mentioned above, the problem with recompiling VIs when changing a global or SubVI connector pattern is not a version control issue, but LabVIEW behavior.
But I disagree with tst that committing every single recompiled VI is useful as this might cause lots of conflicts when multiple developers are working on the same project. We're using conditional disable and different targets so VIs recompile basically always. I try to keep track of the changes and commit only VIs which I really did modify (keeping track of the changes is anyway good practice so one can write a meaningful log message). From time to time, we do a mass compile (for a specific conditional disable symbol) and commit all modified VIs to have everything consistent.

Just my 2c.
Daniel