First time poster, long time lurker. Over the last decade I have found answers to a myriad of Labview related questions I've had on these forums, and I'm hoping some of you can help me out with my current conundrum.

I've a solo developer for a large labview based automation project. I have worked with other labview developers in the past, but we've always kept what we were working on very compartmentalized because nobody ever wanted to deal with LVMerge. At the time they all said Labview effectively had zero way to merge VIs.

Since those old days (9 years ago) we've come a long way. Unfortunately like many engineers I am horrible about UI/UX design - I'm trying to fix basic functionality, I don't care that you can't find the button (at least I don't care right then). But because of how solid the software is getting we're finally in a good position to start dedicating time and effort into improving our UI flow and design. 

So in the run up to this, and knowing I had basically zero experience with LVMerge/Compare except that the previous developers considered it "impossible", I did a few tests. My goal was to continue some development in the block diagram of the main top level VI in my own git branch, while another developer worked on UX changes on a second git branch. Then when he was ready we'd merge everything back together. All of his changes were focused on the Front Panel - he never opened the block diagram once. He was moving things, resizing things, changing captions and boolean texts, but never labels, and then adding various decorations as he wanted for clarity and organization.

My initial test merges worked flawlessly. I was surprised how easy my small merges worked. From there he tinkered away when he could over 4ish weeks on the UI and I kept my usual pace on the main top level working on various bugs. I tried to limit what I was doing in the top level - most of the block diagram changes I made were cosmetic. It needed some TLC.

Anyway fast forward and now we're ready to merge everything back together and ... I can't. I cannot get it to work. I've tried so much stuff. At first the errors were almost always during the LVCompare phase, usually about an insane block diagram object on the "base" vi. I'm familiar with heap peak so after a crash I'd comb the error log as well as I could (wish that thing had some documentation) and then try to find the offending object and fix it. More often then not I wouldn't see an issue with the object at all, and lots of the advice online is "just delete and remake the object" but I hate that solution because it means I fundamentally don't understand the actual problem, and when I'm merging three different versions of a big VI that gets tough to do.

I've been experimenting with the tools, and eventually turned off auto resolve. Okay cool that would get me through the compare stage and actually open LVMerge where I could select which versions of things I wanted. From here it became a game of cat and mouse where I go through changes one by one till I get a crash, investigate, fix, change something related to said crash, and then run it again. This has been time (and sanity) consuming.

It never worked, and eventually I got stuck on a merge change that I couldn't even identify what it was changing between the three, but I know that no matter which I select it crashes. I've kept trying various things since then.

• Resizing the tab control positions to be exactly the same
• Deleting a few FP objects on the base and FP update versions that I had removed when making BP changes on my version
• Adding a few objects I created for the same reason
• Added all 3 versions of the VI to the main most up to date project, opening and running them all to make sure there are no serious insane objects that are breaking them. They all run.

This is by no means an exhaustive list of everything I've tried, but its what comes to mind right now as the major tries. Currently the state I'm in is that when I run it with all 3 versions with all the changes from above made to them, I can't get through the Compare stage because it crashes with a insane object error about "undo.cpp" which makes zero sense to me. What is it undoing? I tried limiting the number of Undos in LV settings, that didnt help, I tried increasing the limit greatly, that also didn't work (maybe didn't increase enough? Trying that now). 

I'm really deep in the weeds on this one now, and I would love some fresh perspectives. What's probably going to happen is that I'm going to write it all off as a lesson, and we'll just have the UI dev make his changes again on my current most up to date version - but I would really love to figure out the compare and merge process, and best practices for using it. The documentation for these is abysmal. There's basically nothing. I could probably pay for NI's annual subscription and maybe get some direct help from them but I had it out pretty big with some NI sales guys a few years ago when they transitioned away from perpetual licenses to the subscription model, and I don't want to pay them on principle; but I will if needed.

Ultimately even if we do the changes again, I'd still like some best practices on where we went wrong and how to avoid this in the future. We're growing fast, and I could see having another full time labview developer working with me in the future and would love to come away from this with as many answers as possible on how to work in a team on labview binary files. 

If you've made it this far all I can say is thank you. Now please send help.

PS: some info I should of added

• we use Labview 2021. I don't think we're on SP1, I don't remember why not, and I am willing to try updating.
  • also willing to pay the sub and just upgrade to 2025, but not without good reason like someone tells me all about how they solved so many issues with Compare/Merge in the last 4 years and its going to be so much better
• I'm attaching my most recent error log from the crash I had last night. Its a doozy, reporting a TON of objects on both the FP and BP as insane.

lvlog2025-08-11-15-32-09.txt

I have LV 32 and 64 bit installed on my PC and am unsure how to handle adding in LV Compare/Merge.  I say this because, as far as I am aware, TortiseGIT can only run 1 program per file type.  When talking with ChatGPT about it, ChatGPT recommended making a script that checks the file's "bitness" then running the correct version of LV Compare/Merge and use that script as the "program".  To me, it makes sense, but I also do not know what I do not know. I wanted to see if other people have run into this issue and what their solutions were.  If it's a "google it" thing, can I get some direction regarding what I should be searching for?  I don't mind putting in the legwork to learn, but I also don't know where to start with this issue and I've been flailing around in the dark for a bit and it's getting super frustrating.

Thanks.  

cd && git clone https://gitlab.com/sas-blog/LVCompare-Merge-Setup.git && cd LVCompare-Merge-Setup && ./setupLVTools.sh

For more info checkout the repository here:

https://gitlab.com/sas-blog/LVCompare-Merge-Setup

Demo'd here:

1. Save both of the attached files someplace permanent on your hard drive that is outside of any particular git repo. We used

   C:\Users\<<username>>\AppData\Local\Programs\GIT\bin

   _LVCompareWrapper.sh_LVMergeWrapper.sh
2. Modify your global git config file. It is saved at

   C:\Users\<<username>>\.gitconfig

   You need to add the following lines:

   [mergetool "sourcetree"]
   	cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVMergeWrapper.sh' \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"
   	trustExitCode = true
   [difftool "sourcetree"]
   	cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVCompareWrapper.sh' \"$REMOTE\" \"$LOCAL\"
   [merge]
   	tool = sourcetree
   [diff]
   	tool = sourcetree

That's it. There are lots of ways to edit the .gitconfig from the command line or by using SourceTree's UI... if you know those ways, go ahead and use them.
 

Has anyone gone down one of these paths?

In git there are several different options for checking out a commit (checkout commit, checkout branch etc) and I never really paid much attention to the subtleties of these. As far as I thought they all did the same thing, that is revert the local code to the state of that commit.  It turns out that my understanding was flawed, and every time you check out a single commit (rather than the actual branch) the current state will not point to any particular branch and you will be in the detached head state.

I find this a bit weird, as I presumed if you checkout a commit in say the middle of a branch somewhere you would still be on that particular branch. Checking out a branch will always checkout the latest commit of that branch.

This article explains it nicely.

I have not been too scared of detached head for a while now as I know it can be easily fixed just by making a new branch, but it is nice to know why this actually happening.

Happy gitting!

(next step in my git mastery is to understand the subtleties of local and remote branches).

I have been using TortoiseGit + Bitbucket for SCC for the past year and I have become rather frustrated with a recurring problem that I simply cannot find evidence of others experiencing.  For that reason I am convinced I am doing something wrong in my workflow but IDK what.

TortoiseGit flags changes to some files but when I use LabVIEW to do the diff/compare it finds no changes at all.  The file sizes of the falsely flagged files are unchanged, but the CRCs are changed. (inspected the binary difference below).  Before committing the changes I do a mass compile as NI suggested to me that might be the cause.  At one time that seemed to help, but not now.  Also I can confirm I have enabled the separation of source and compiled code in each vi and in the project.

WHY does this happen ?

Here are examples of file names and sizes that are unchanged (but falsely flagged as changed by TortoiseGit):

 Interpolate Magnitude (3 pts).vi       |  Bin 14665 -> 14665 bytes
 Order Magnitude from FFT [dB].vi   |  Bin 13741 -> 13741 bytes
 Peak Find 3 pts.vi                              |  Bin 21587 -> 21587 bytes
 Vector Sum [linear].vi                        |  Bin 12555 -> 12555 bytes

and one file changed which was truly flagged as a changed (note filesize diff)

Amendments.vi                                  |  Bin 54814 -> 54786 bytes

In one of the above files, below you can see the binary difference of 5 bytes occurs just prior to the first revision history comment, however no changes at all are found in all the history comments nor in the LabVIEW compare.  I spotted a similar kind of change (same location)  in a 2nd file I looked at.

In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project…

My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?.

Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling

Thanks!!

I've been programming LabVIEW for over 20 years in a single one technician lab and never really needed any stinking source control. Well now that's not the case. But thought I'd just read some posts, determine what everyone else likes and be done!!!!! That didn't work out for me ether... Seems nobody really likes source control after all. Or at least there are issues with just about every option.

So here is my situation. I'm still the single labVIEW developer on a project. But the project requires a more structured source control environment. So I'm looking for source control that works flawlessly within LabVIEW and  is easy to use, I'm Using latest versions of LabVIEW.  

Since most of the posts I read today are from years back, I'm hoping things have really improved in the last couple years and you guys are happy as a lark with your source control environment.

If you could take a minute and tell me:

1. What type of source control software you are using?

2. You love it, or hate it?

3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else

4. Pro's and Con's of the source control you are using?

5. Just how often does your source control software screw up and cause you major pain?

Thank you in advance.

Bob Harmon

So I must be doing something wrong.  What should I read up on to make Git less crap?

But what is this all about? I have done a bit of digging and it seems the current best practice is indeed to delete the branch when it is no longer needed. This is also a totally strange concept to me. I presume the branch they are talking about here is the remote branch?

Confused...

I work with a small team with a badly overdue need for SCC. I find myself in a position to change some things, but, unfortunately, I've spent most of my career here and I'm a bit lacking in experience myself, so I've been looking into available options for a few days. The more I research, the deeper down this rabbit hole I go. Maybe a bit of discussion will help solidify the tools and features I'm looking for, and this seemed a good place for it since "works well with LabVIEW" is a factor.

Ramblings from here out...

Current state: Madness and chaos.🤪

Desired state:

• VCS repository management including either on-premises or cloud storage.
• Project management/issue tracking.
• CI/CD might be worth exploring?
• Documentation. A wiki or similar that can document the applications would be great.
• Due to the industry we are in, user management is sort of important. Ideally I'd like to use SSO and enforce dedicated accounts.

Thoughts on possible solutions...

• Gitlab
  • Seems the most likely Git contender. Bonus points for the fact that it can be self-hosted, which mitigates some of the user management concerns.
  • That said, see drjdpowell's recent thread for the type of discussion that makes me nervous about rolling Git out to an inexperienced team, especially under my not-exactly-expert guidance.
• Perforce + Jira + Jenkins
  • I believe our software engineering group is using something along these lines. (Not sure what their CI pipeline is.) This loses a some of the appeal of a single application, but I do think I would prefer the idea of a centralized VCS for our situation.
• SVN + ???
  • Maybe my Google-fu is off, but I'm not turning up a ton of modern guidance on a full tool chain. Helix Teamhub or Assembla along with Jenkins maybe? (Except I just noticed Assembla says their Jenkins plugin only works with Git... Hmm.)
• Azure DevOps
  • Can anyone share experience with TFVC or Pipelines? I haven't actually tried any of these tools yet and I'm not sure if it's worth pursuing, but the website is looking... surprisingly not bad. (Although even they seem to be pushing users toward Git.)

Also tried Github and Bitbucket. Found myself leaning towards Gitlab over Github, and prefer not to talk about Bitbucket. 🤢

It seems that it takes issue with the URL of the repo and the newness of the files.

Here is a post about WS.Reputation.1: https://community.norton.com/en/forums/clarification-wsreputation1-detection

They suggest that developers set up auto-protect exclusions for their project directories.

Thanks.

For all of you who still use Mercurial and host your open source and/or enterprise repos on Bitbucket, this blog post is worth reading:

3 hours ago, LogMAN said:

Thanks for the heads up, this completely went by me.

Here is the official blog post from Bitbucket if anyone is interested: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

So this question is mostly to get community feedback on what approach you use to handle this, if at all. I went down a rabbit hole recently on one big project. I decided to keep ONLY source code in GIT and move all support files to dropbox. I also tried putting the build output and other transitory files to dropbox as well. However I found an issue because dropbox would interfere with the build process (any insight to this from others is welcome).

Thanks for your help.

Within each Project we have our source organized into folders like this:

Project Folder
	Configuration Data Folder
	Source Code Folder

We typically do development on our development machines where the Configuration Data Folder contains configuration files that are in simulation mode and using atypical configurations.

We also deploy our development system onto tools during development and testing by cloning the repo onto the hardware supported platforms.  On these machines, the configuration data is modified to remove the simulation flag and is further configured for the specific project being developed.

When we do a pull onto the deployed systems, we definitely want all the Source Code Folder changes but we generally do not want the Configuration Data.  However, we want the Configuration Data to be tracked, so we do want it to be in the/a repo.  Does anyone know what the best method to do this is?

What we don't want to happen is for the deployed system configuration data (which might include some machine specific constants, etc) to get over-written by some developer setting that was used for testing, but we still want to pull/merge changes onto the tool.  Note that we have the tool on a separate branch from the development branch but when whenever we merge we can potentially get into trouble if we pull configuration data as part of the sync.  Since the configuration data is text based, Git typically auto-merges these changes and so it can be difficult to tell that the merge affected the configuration data.  I am curious if anyone has had this issue already and come up with a good solution/strategy.

I am fairly new to Labview development.  I want to implement revision control software (SVN in particular) to my workplace.  Before I can do this, I need to prove the concept and usefulness of the SVN application for us.  I have used SVN in some degree in the past, and noticed tortoiseSVN integration with Labview via the TSVN Toolkit.  I have a few questions regarding SVN and how I should organize my project files, in particular when using SVN.

File organization has been a particular gray area for me in Labview, unlike linking my libraries and specifying their locations I don't seem to quite have that control in Labview.  This issue is somewhat more exacerbated (or at least so I think) when I began using SVN.  Let me explain: Using the TSVN toolkit it sees that my entire class (which was developed in a separate directory - then linked in) is not sourced and revisioned.  This is also the case for several other libraries which I have borrowed or developed myself.  I have two primary questions regarding this.

The first - How does SVN add/commit these project files when they are not present within the project directory itself?  In fact I have created a separate repo for the class which I use to maintain that code.

The second - Is my file organizational design fundamentally flawed? Especially in the context of SVN?  What are some good organizational tips/ schemes (when using SVN) which would help me for future projects in avoiding issues such as this? 

A  less pressing question:

How well does the "merge" functioning work with the Labview VIs?  Remember I am do not have the most experience with SVN - it is my understanding that merge basically would merge changes I have made back with changes by other devs to the file along the main trunk(?).  

Thanks in advance.

MrShawn

They referred me to the following links:

http://www.gnu.org/licenses/gpl-2.0.html#SEC1

https://softwareengineering.stackexchange.com/questions/47032/can-i-use-gpl-software-in-a-commercial-application

Is this correct? they want me to use TFS and if I understand correctly it is GIT based and not working as good as SVN with LabVIEW.

If they are correct, the second I use a tool from VIPM which is GNU GPL I need to open MY OWN CODE!

Is that correct?

sorry to start a new thread on this, but my searches turned out posts that are mostly outdated or relate to SCC tools other than SVN.

So, we have decided to use SVN as our SCC platform. I have setup a VisualSVN server on our Windows 2012 Server and Tortoise SVN client on the developer machines. This is working quite nicely at the file level, but I wonder if we can get more functionality, especially VI comparison.

We are using the latest LV 2015 Full Development System (not Professional Development system). So I understand that I cannot use the lvdiff tool. I have however setup LVcompare as a tool for .vi files in the SVN Advanced Setup.

I found two SVN tools for LV:

1. JKI TortoiseSVN Tool. This has a somewhat steep price at $200 per developer (10% discount from 5 seats)

2. TSVN Toolkit from Viewpoint Systems. This is free. However, it states that the latest version supported is LV 2014.

I am interested in the experience from other users regarding:

Q1. Which of the two tools, if any, do you find useful and why?

Q2. Does TSVN Toolkit work with LV 2015?

Q3. Any other tips/suggestions for effectively using LV with SVN?

Your opinion and help is much appreciated.

Thanks in advance.

--germ

Is there any VIPM alternative out there?

If not, It will be very interesting to start a discussion whether an open source version is feasible and how many members in the community are willing to work on it.

I know JKI has a great product already but seems like development has come to halt wrt VIPM.

Any comments?

This VI will find files (VIs, Controls, Classes, etc...) in your project folder that are not linked by a given top-level VI. This is done by comparing the call-chain of the top-level VI with the files on disk. It assumes your files are in folders relative to the specified root directory. This also means that files outside the hierarchy will be ignored (vi.lib and such).

Be aware of (at least) two things:

1. This VI will return false friends if you happen to have any "Open VI Reference" call with constant VI names or paths connected to it (not a problem if you use static VI references).
2. VIs in diagram disable structures are not listed in the call-chain. So if you use conditional (or regular) disable structures this VI will return false friends.

Does anyone know a solution to number 2. actually?

Hope this proves useful to you too.

We do have a SVN server running, however the network changes from when the current owners took over have FUBAR our ability to connect to SVN from our desk. This appears to be a much needed effort to version control the PLC programs (long overdue) and an attempt to close out IT work tickets that are many years old.

Thanks in advance for any replies.

Here are a couple of options;

1.  Take a copy of each library the project depends on and check it in to the project repository. Causes duplication but all the custom libraries needed for the build are then in one repo, with the right version.

2.  Install the custom libraries to vi.lib/user.lib. There is less duplication but if someone checks out a project they now need to know to check out the dependent libraries. Plus, if different projects on the same machine depend on differnent revisions of the library it becomes more fiddly.

Martin

Notes:

I know how to configure TortoiseSVN to work with LVCompare and LVMerge.  My new employer is moving to Git (some good, some bad in that, in my opinion, but that is another topic).

I have been using Git for a few months now with reasonable success and decided I should try to set up graphical differencing.  [OK, in practice I've rarely used graphical differencing for any practical purpose, and graphical merging probably never for any actual code.]  Anyway, I think I've learned some things trying to figure out how to get this to work--but I don't have it working yet.

I use the Atlassian SourceTree client at present (and sometimes the shell).  For the purposes of this discussion it might be more helpful to share the relevant text in the .gitconfig file (and any associated scripts, if necessary).

As others have mentioned, Git itself (SourceTree similarly) does not distinguish which diff tool to call according to the file extension.  This seems like it could be a significant drawback.

What I have tried:

I added this (and variants of it) to my .gitconfig file:

[difftool "LVCompare"]     path = C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe     keepBackup = false     trustExitCode = false[difftool "LVCompare"]     cmd = "C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe"  "$LOCAL" "$REMOTE"[diff]    tool = LVCompare

SourceTree reports errors on start-up, so don't use this!  Lol!

Maybe I need to add a script, too.  I'm not sure that I'm really all that close, honestly.

[bigger question: Why is this difficult in the first place?]

My intent is to have a data type which has a version string, and a variant for the data which will be read according to the version number in the version string.  The issue is that if you flatten the data type to an XML string with any data in the variant, then try to unflatten the data, you get an error (1106: "LabVIEW:  The XML tag describing the type of data does not match the wired type.")

How have you done versioning for data files which you are pretty sure will change over time?

And can anyone tell me why this attempt doesn't work?

Thanks,

-Chris Collier

P.S. The attached files are in LV 2014

Test XML.zip

• a whole group of items within "Dependencies" is replaced by another one. Where linux has
  

  <Item Name="System Exec.vi" Type="VI" URL="/<vilib>/Platform/system.llb/System Exec.vi"/>
  <Item Name="Get Web Browser Path.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Get Web Browser Path.vi"/>
  <Item Name="Get System Web Browser.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Get System Web Browser.vi"/>
  <Item Name="Prompt Web Browser Path.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Prompt Web Browser Path.vi"/>
  <Item Name="Dflt Data Dir.vi" Type="VI" URL="/<vilib>/Utility/file.llb/Dflt Data Dir.vi"/>
  <Item Name="Create Directory Recursive.vi" Type="VI" URL="/<vilib>/Utility/libraryn.llb/Create Directory Recursive.vi"/>

  windows puts a longer block, which includes Registry VIs, ActiveX VIs, BMP VIs and more. I presume that at least some of these deps are due to a little use I make of Report VIs specifically.
• the entry line for item lvanlys.so is replaced by lines for lvanlys.dll, Advapi32.dll, kernel32.dll
• the three lines in the Build Specifications block
  

  <Property Name="Bld_supportedLanguageCount" Type="Int">1</Property>
  <Property Name="DestinationCount" Type="Int">2</Property>
  <Property Name="SourceCount" Type="Int">2</Property>

  are moved around at different points within the block.

Don't know if I'm going to make a big fuss about, just remarking...

Submodules in git are pointers to a specific commit in a repository at a specific URL. This is evidently different than externals in svn, but both are intended to solve the same set of issues.

http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer

[T]here are a number of use cases for [submodules], and they all center around nested git modules that are much more static in nature and use.

One - you have a component or subproject where the project is undergoing extremely rapid change or is unstable, so you actually want to be locked to a specific commit for your own safety. Or, perhaps a project is breaking backwards compatibility of their API and you don’t want to have to deal with that till they stabilize their code. In this case, git submodules, being reasonably static, are protecting you because of that static nature. You don’t have to clone the outside component and switch to a specific branch or go to any of that hassle - things just work.

Two - you have a subproject or component that you’re either vendoring or isn’t being updated too often, and you just want an easy copy on hand. To provide an example, in my dot files, if there’s a vim plugin I want I can just add it as a git submodule, and it’s done. I don’t care about the history. I don’t need to be at the latest version. I don’t plan on doing a lot of work on that code myself. Since this entire workflow is static, things work fine.

Three - There’s a part of your repository that you’re delegating to another party. Let’s say you’re paying someone to write a plugin for a project you’re using, and you need to develop on the main codebase. In this case, the plugin repository is chiefly developed by the plugin developers, so they own the repo and periodically they’ll tell you when to update submodule commits. Submodules are great for dividing responsibilities like this, assuming that there’s not frequent updating.

 

Right on! #2 seems right up my alley.

However, everyone in the git universe abandoned them over the last couple of years because of several issues with brittleness and complex git workflows.

https://github.com/cristibalan/braid

Vendoring allows you take the source code of an external library and ensure it's version controlled along with the main project. This is in contrast to including a reference to a packaged version of an external library that is available in a binary artifact repository such as Maven Central, RubyGems or NPM [ed: or VI Package Network].

Vendoring is useful when you need to patch or customize the external libraries or the external library is expected to co-evolve with the main project. The developer can make changes to the main project and patch the library in a single commit.

The problem arises when the external library makes changes that you want to integrate into your local vendored version or the developer makes changes to the local version that they want integrated into the external library.

Still, I can't help but wonder if these complaints would be minimized in my use case. Then a really important, LabVIEW-specific issue hit me:

LV code is compiled to its version, and it can't be opened by an older version of the LV dev environment. I wouldn't be able to push changes made in a local submodule back to the remote library repo unless my code were back-saved to the remote's version of LV. (For example, I made a pull request against NI's STM repository recently but had to leave my code in a later version than theirs.)

How the heck do we use tools like submodules/externals and the fork-pull workflow without being forced to upgrade all our LV code to the latest version (and re-test it, often against RT or FPGA hardware) every year when NI releases a new runtime? That's a dealbreaker for me because of the risk involved in upgrading existing projects to new drivers, runtimes, etc. (I've seen bugs introduced with a new version of LV that broke previously working code.)

General pointers to how automated builds (specifically LV) are handled by other SCC also appreciated, for my education.

He calls forward lots of niggling doubts that I've deliberately squelched over the last few years, but I can easily recall a time when trying to learn gitflow that I paused and asked myself, "Is SVN really so bad that I'm spending my evenings trying to do this instead?"

You now have a Perforce workspace with revision #0 of each file checked in. The convention from here on out, is to add files to the LabVIEW project file. Each time you do this, LabVIEW will automatically prompt you to add the file to Source Code Control. Before you can do this, however, you still need to configure LabVIEW's Source Control. In the LabVIEW "Tools" menu, select Source Control -> Configure Source Control.

Select "Perforce SCM" for the Source Control Provider Name. Click the "Change" button next to Source Control Project to configure the project. Navigate to the LabVIEW .lvproj project file that you wish to bind to.

*NOTE* - you will need to change this for each unique customer or project that you are binding to. Since you can have multiple workspaces and multiple projects, you must make sure this is configured properly for the Perforce workspace that you are bound to.

 

Is the author saying that I need to click Change and then navigate to a different SCC depot location for each different Labview project file I work on?  And then does that project remember that depot location for next time it's opened, or is only one location remembered as the global Labview SCC configuration option?

Thanks.   -Joe Czapski

I have used different SCCs for various text-based projects in the past, like cvs, svn, git, and I'm familiar with the idea.

Now I decided to adopt git (namely hosting at gitlab.com this time, for convenience) for a big LV project which screamed for it since its beginning, and I'm tucking fine with that.

.

However, git itself is agnostic in treating all my vis, llbs and so on like binary files. That means to me that my repository grows in time at a quite fast rate, and that diffs are completely obscure.  I am not able to tell for instance if an llb changed because a single vi was recompiled or because of more extensive changes. That may ultimately constrain my strategy of committing, for example avoiding llbs at all in favor of subdirectories in order to gain in granularity, or reducing the frequency of updates to limit size blowup.

I'm also missing specific tools for, say diffing and blaming files in a LV meaningful way. This in contrast to text-based languages. In the present project my only text files are .lvproj, .lvlib, some xml configuration files and lyx documentation, not the core code, so that doesn't bring me very far. To compare two snapshots of the project I presume that I would have to create two copies of it on disk, rename some relevant VIs, load both copies in LV and compare them... not inspiring as a workflow. Is it all one can get, or am missing the obvious?

I mean, after all what is this Tools/Options/Source Control/Provider name thing, and why does it display "<None>" in the pulldown? Oh, help: "On non-Windows platforms, LabVIEW runs a query to determine if Perforce is installed". So what, I can do SCC only if I depend on a single commercial service provider? Can't believe...

I've been experimenting with using Mercurial for my SCC.  I've come up against this problem and I'm wondering if anyone else has found a good way of dealing with it...

If I want to rename a file that is in the repository then I would use the Mercurial Rename function so that all the history is kept.  However, if I do this then the LabVIEW project doesn't know the file has been renamed and gets upset that it can no longer find it.

If I do it the other way round and rename the file within the LabVIEW project and commit the changes, then Mercurial things I've jsut removed the old file and added the new and the history is lost.

Can anyone help with this please?

Thanks,

Martin

LabVIEW 2013 | CLA

I'm getting ready to write a utility that will allow me to "download a file from Git" at run-time. Disclaimer: I have not used Git much.. anyhow, I'm hoping I can leverage from any work done on this front.

By the way, when I say "I'll write a utility" I'm thinking of C# or Python as the programming languages I would use. If in C# I can easily output a DLL and such would have a LabVIEW wrapper. If in Python, I'll try to create an executable with parameters, then I'll put a LabVIEW wrapper around it. I have written several utilities this way, therefore, I am certain this approach will work.... Someone could ask though: "is your approach the right one"? let's just assume it is :-) but, I'm open to ideas if you feel like sharing.

Details:

My test program -written in LabVIEW- uses two types of configuration files (.ini, .csv). 

The CSV files I use have a version hardcoded in it   e.g.   version, 14.9.29.01    (year.month.day.rev)

Additionally, I have a table (SQL database) that keeps the "RELEASED file version-repository version relationship". E.g.   14.9.30.01, 123

At run time, my LV program gets the local file version (LocalFileVer = 14.9.29.01) and also retrieves both, the file version, and the repository version    ReleasedFileVer=14.9.30.01, RepoVer=123 from the database.

IF my "LocalFileVer"  DOES not match the "ReleasedFileVer" I would like to download file ver "123" from Git.

Has anyone done something similar to what I have tried to describe here? if yes, would you mind sharing? I'm looking specifically to download files from Git though, and not other version control apps.

By the way, I have been able to do what is described above for SVN. Unfortunately I don't have access to the source code... At the time I was doing contract work on a machine that was not "mine". Anyhow, at the time I used C# to write the utility. 

I look forward to any comments.

Cheers!

I have a few questions:

What is the best way to move files from one project folder to another?  The "move on disk" doesn't appear to be a good option.  I want to be able to make file moves if needed and don't want my project to end up blowing up with conflicts.

It appears that once source control is set up in LabVIEW that all check in/check out operations need to happen in LabVIEW and not TFS or windows explorer.  Correct?

I just noticed the "Include callers when checking out files" option.  I am assuming that is probably a good option to select so that they callers will be modified and saved as needed.

Does having files set up as auto populating have any negative effects on how source control is done?

Unfortunately it appears that we are stuck using TFS for source control since the firmware developers are using it and it is a company application now.

Any help or guidance you can provide would be appreciated.

Thanks.

Joe

Recently I moved from SVN to GIT as my source control and revision manager.  I'm still getting used to everything so i don't consider myself an expert yet, but i really missed the Project Provider options that I used for SVN source control within the project window.  

I'm releasing an open source beta project provider for TortoiseGit Integration.  This addon is very similar to the current SVN options but was developed entirely from scratch.  Currently this provider requires TortoiseGit to perform most of the Source Control Actions.  I know a lot of you on here have recently switched to sourcetree, however, unlike TortoiseGit they do not currently offer a command line interface yet for windows that i could find.  I've tried to make this project flexibile and if they offer a command line for windows eventually it should be fairly quick to re-factor for that.  

The project can be found here: https://bitbucket.org/jed_d/lv_tortoisegit

Addon Features

• Tortoise Git Icon Overlays within Labview IDE
• Tortoise Git Commands from within Labview IDE
• Ability to directly reload a project from within the Project Window, as well as prompts to reload the project when performing actions that require a reload.
• Open Git Bash from project window
  

I'm hoping some of you will have a chance to try this out and let me know of any issues.  I would like to track issues on bitbucket if possible so that they are all in one place, but i will also be checking these post for issues as well.  

Feel free to fork the project and hack on it yourself.  If you come up with something decent and don't mind sharing, send a pull request.  

One initial issues i'm hoping the community can help with is building the package for older versions of LV.  Currently i only have access to 2013 so i am only able to build the package for this version.  If anyone has a change to pull down the repo and build it for older versions please do.

Another question i have for the community is the license i currently have on the project.  This is my first open source project of any kind so i wasn't sure what license to put on it.  I did not want to be too restrictive so i went with a BSD license.  If any of you see an issue with this please let me know as I'm open to suggestions.

Can anybody refer me to a proper URL?

After contacting GitHub support asking the proper channel for submitting a .gitignore to their set of templates, i received the following response: "We have an open source repository, https://github.com/github/gitignore that we use to accept contributions for the gitignore templates. The way we accept new contributions is through pull requests" From the readme.md on that repo, "Since this repo includes a large and diverse number of programming languages, frameworks, editors, and ecosystems, it's very helpful if you can provide a link to information supporting your pull request" -- we will use this thread and public discussion as documentation and justification for LabVIEW.gitignore.

So, I went ahead and forked the repo and created a new LabVIEW.gitignore, found here: https://github.com/wirebirdlabs/gitignore/blob/master/LabVIEW.gitignore

Please, feel free to contribute to this thread, and once we've come to a consensus, hopefully GitHub will accept the Pull Request.

Here's the contents of the file right now:

# http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/lv_file_extensions/*.aliases*.lvlps

I'm in the process of setting up a server to serve all of our yet-to-be-created Mercurial repositories from.  Given in Hg that each project will have its own repository it seems to me that a flat folder structure is the way to go ie:

CodeBigApplication1

CodeBigApplicationN

CodeSmallApplication1

CodeUsefulLibrary1

CodeUsefulLibaryN

Although with all the applications and libraries that get created this will mean there are lots/hundreds of repositories with no sub-folder structure, I can't see the benefit of organising the repositories into sub-folders.  In fact I can only see a benefit of not having them, ie simpler relative paths when an application uses a library, no funny grey areas on whether a library should fit into sub folder a or b etc.

Any thoughts on this please? Am I missing something?

Thanks,

Martin

I am looking for suggestions, tools, etc to simplify checking in code (committing for SVN).  At the moment, we have to use SVN and it is unlikely to change. 

A quote from Jim K in February 2011:   "Jim Kring demo the JKI TortoiseSVN Tool for LabVIEW and talk about the next big thing: Distributed Version Controls Systems (DVCS) and the benefits they will bring to software engineering in LabVIEW."

Did anything evolve from this?  Does the JKI Tool support multi-user in the sense that it facilitates commiting code with SVN without having to resolve any conflicts.  I am mostly concerned with mis-matches with the lvproj, but SVN should be able to handle that with Merge or Compare functions. 

Any comments on this topic?  Euh... yes, I am aware that there are other Source Control than SVN, but that is way beyond the realm of my influence. 

Thanks,

RayR

https://jazz.net/products/rational-team-concert/

I'm about to pick a Subversion client for MacOS X to use with LabVIEW, I read a couple of reviews (mostly from here on stackoverflow) but before choosing I'd like to have some feedback from LabVIEW users.

Anyone can recommend one?

Thanks in advance.

I'm looking for some advice from anyone who has been using mercurial with LabVIEW.

Firstly I have just been trying some branching and merging. After a merge, having been configured for merge using https://bitbucket.or...iew-integration I see some .orig files getting left in the repository. Is this a failing on LabVIEWmerge.exe to clean it up or is it the way mercurial works?

I am interested in the DVCS camps because of merging. I currently use SVN, primarily as a lone developer. I like not having to maintain a separate central repo and the improved merging, primarily from the point of having sandbox branches. I like that in Git, if I have an experimental branch that doesn't work out I can delete it. Is there a similar workflow with bookmarks that can be achieved or am I going to end up with a load of bookmarks littered around the place?

I liked that Mercurial integrates better with Windows and is a simpler way to learn DVCS than Git, but I do also like the look of branching in Git and think the extra flexibility may be a killer feature. That said my general opinion when you get these 'holy wars' is that there is probably no real difference between them, else people wouldn't be arguing so much over minor details!

Cheers,

James

I've recently started using Subverion + TortoiseSVN to manage the source code of LabVIEW projects and I'm now getting to the point where I don't really know what I should do ; untill I had no banches and just revisions and a couple of tags for shipped versions I could handle it.

Now I need to go further than that and manage a large project that consist in an EXE and 3 plugins. The EXE will be shipped to many customers and each customer will have different "flavours" of the plugins.

I'm not feeling confortable enough with SCC usage to decide how to manage this scenario. Multiple repos? Sub-repos (does it exist?), one repo and 1 branch per customer?

The whole source code sums up to about 2000 VIs.

The EXE and the plugins have subVIs in common (some that are user.lib and some that are part of the project).

Any advice greatly appriciated.

Cheers,

Since my boss is impatient and impetuous(probably ADHD because his son has ADHD), I think I can't afford to fiddle with SCC for more than a week.

I read all those threads about Tortoise HG in this forum, but I'd like to give TortoiseGit a shot.

The choice doesn't entirely depend on my preference but would have to be the more stable one.

Which one is more stable?

Should I just stick to Tortoise SVN for stability?

http://www.perforce.com/downloads/try

I have created a new provider based on the existing Perforce.

If I copy this in the Provider folder of LabVIEW I get an extra provider in the SCC options dialog.

However selecting the new provider causes an error.

Does anyone have some pointers about the setup of this provider feature?

Ton

I've installed LVMergeHG and I have it specified as the tool to use for 3-way merging in the Hg global settings. When I open the TortoiseHg Workbench window I can see that I have a branch that I want to merge back into the main trunk. If I select the 'Diff to local..." option, LVDiff runs and I can see the to VI's I want to merge together. If I select the 'Merge with local" option I get a popup window, Prepare to merge, that shows info on the two VI's I want to merge. When I continue by clicking the 'Next' button I get the following:

% hg --repository C:\Documents and Settings\D\Desktop\ZZ merge --verbose --tool=internal:fail 6

resolving manifests

0 files updated, 0 files merged, 0 files removed, 1 files unresolved

use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon

[command returned code 1 Mon Apr 09 16:33:47 2012]

I can't see anything that looks like LVMerge is trying to run. I'm sure I'm probably doing some wrong or don't have something setup correctly. Any ideas?

I played around with Tortoise/SVN and the file based repository and had one other developer along for the ride, so if you want to respond with that as a reference, that is OK too.

This first question is a very basic one. Sometimes a small change in a VI has an incredible echo in other VIs. I am not talking about changing an API for a method. Clearly that would require callers to be updated. I am remembering a change to say the icon of a VI and all of a sudden here is a huge impact. There may be other things. I guess my question is LabVIEW retains the interdependencies, how do you get a handle on these changes as they might impact another developer of a 'somehow' related module?

What is the most efficient way to get some SVN properties like Revision and Author on the VI front panel (e.g. OpenG VIs)? For text files the SVN keyword substitution works very well, for binary files (like VIs) I'm not sure how to handle this without writing some automation code.

I remember that there has been an article about CVS and keyword substitution in LTR once and was looking for something similar for SVN. To my surprise I did not found a clear article yet.

Thanks for any tips?

Donald

Corrolary question: Are there any good open-source SCCs?

George

Thanks in advance,

val

The solution was to recompile the top level VI and save all callers (have to save as its RT).

The problem arose as most VIs were read-only as they were in SCM.

What is the standard protocol for this from SCC point-of-view?

Should I check out the VIs, compile/build/archive-build, then check them back in and tag them as "recompiled" or similar?

Or should I check out the VIs, compile/build/archive-build, then get last revision to overwrite the new local copies?

What do you guys do?

Cheers

JG

This particular add on has many revisions. It is a work in progress as we and the 3rd party do R&D on the application. In addition they are primarily PhD's in something other the Software Engineering. The code shows this and noteably the pinouts to the applications VIs change from revision to revision.

I think the OO jargon for this is Highly Coupled, meaning certain revision of our code work only with certain revisions of thier code.

We have a situation where instead of any developer being able to do a build at any time, only one or two machine can succesfully build this project.

I was reading other threads on this forum, specifically http://lavag.org/topic/13492-reuse-packages-and-scc/ and it looks like VIPM might be an answer. But I have specific questions about how it would work.

Apparently there is a VIPC file that would be committed to SVN or any SCC. When exporting, a developer would use this file in some way to verify that the right version of the packages are installed. Is this correct? What is the "some way"?

Will this process downgrade the 3rd party add on as needed?

Presumably also the VIPM would in some way make sure there were not two version of the packages in the VIPC, or do something else to prevent cross-linking?

So the way I imagine the use would be:

Checkout the code from a previous revision.

Update the 3rd party add ons to the correct version based on the VIPC file.

Build the binary and installer.

Delete working folder.

Or if a we needed a branch of a previous revision say 5.1 from 5.

Checkout version 5.

Update the 3rd party add ons to the correct version based on the VIPC file.

Make the required 5.1 revisions.

Check the VIPC for new dependencies.

Build/Test/Validate etc...

Commit changes including VIPC.

Is that right and does VIPM handle the package updates and dependency checks?

Thanks!

At the moment I'm running TSVN on the server and commit/update/checkout every day manually through windows explorer.

My goals are to make my work more efficient by:

1. Making TSVN accessible from the tools menu like JKI TSVN is.

2. Adding Hackystat telemetries into TSVN.

3. Adding TSVN to LabVIEW's source control providers.

4. Making TSVN work with LabVIEW blocks from the pallet Connectivity->Source Control like SCC Open SCC Project vi.

5. Adding a Bug Tracking capability to TSVN.

The way I thought to implement it is:

1. Since I can run TSVN from the command prompt and since I can add vis into LV tools menu I thought I can add update/commit to the current vi/project I'm using.

2. Hackystat http://en.wikipedia.org/wiki/Hackystat is supposed to integrate with TSVN. I don't yet know how. Did anyone here try it before? Do you guys use any kind of a metric system both to collect data about the work being done and for the way users are using your code like time efficiency parameters and so on?

3. I have no clue. Help someone?

4. I guess it would be possible only after I complete stage 3 since I got an error trying to detect with those block if I'm using TSVN. Am I right?

5. I created a structure that allows me to handle bugs by each user to each project with permissions and all. Now I only have to write a GUI that allows users to report a bug that will save not only the description but also the programs state and a video by Jing. Then, I would like to load the report folder that contains LVM file of the configuration and the video to TSVN. Once I update the bug folder I will run Data Finder on it to display the list and apply blocks like Merge Queries to find whatever I like. However, I don't know if it is the smart way to do it mainly because I didn't do such things in the past and I wonder what will happen if two people commit with conflicts.

I'd love to hear any comments and advice.

Thanks in advance,

Dror.

A quick search didn't reveal any titles appearing to address this specific question...

My application's source-code is organized under two directories - a project-specific directory where all the sub-VIs and directories are part of the application, and a "utility" directory which contains a hierarchy of generic functions used by many projects.

When releasing an application revision, (i think) it's necessary to create a tag in order to obtain a snapshot of applicable VIs, however, if the tag is applied to the "generic" folder, it will be applied to many VIs, the majority of which are not applicable to the release.

I'm relatively new to SVN and wondering if SVN and LabVIEW can be integrated in a way that would allow a tag to be applied to [only] the dependencies of a top-level VI.

Any ideas, including alternative approaches, are welcomed!

I am looking for any and all comments on this topic from the LAVA community :

I am a LabVIEW programmer who has been "forced" to use Clearcase for several years now by the text based coders in the dept. It seems that there are now more LabVIEW programmers that use TSVN and SVN than any other SCC tool out there in industry (my perception), and I am sure for good reason and not just due to cost savings !!!

I would like to present a functionality / ease of use comparison case between ClearCase & TSVN / SVN to justify the potential migration to TSVN & SVN.

Thank You in advance !!!

I'm in the FIRST robotics community, and next year we're getting a copy of LabVIEW 8.6 Pro which has the a few programs included for use in source control.

Anywho, we're interested in using some sort of source control to keep track of our code and allow simultaneous development with several programmers. A quick Google search shows little or few relevant results of using LabVIEW with Git.

I'm wondering if any of ya'll, LabView users, have ever used Git for tracking your code? If so, how have you accomplished it? If not, what have you used that is free to use?

Any information would be helpful.

Thanks

-Tanner

I was reading this article today about the growth of GIT and I found the figure below quite interesting, plus there were a few comparison comments that were informative.

but Eclipse's 2011 survey of 704 developers still has Subversion as the source code management system of choice, with 51.3 percent of respondents using it. CVS, also a centralized system, comes in second at 13.3 percent. Git follows with 12.8 percent, while Mercurial was used by 4.6 percent

It placed the user base of GIT as much greater than Mercurial and yet I have noticed in the LabVIEW world a general settling on Mercurial & SubVersion

cheers

Danny

First i found Visual Guide to source control to be a great resource to explain source control to my colleges.

2nd:

Requirements Analysis.

I have multiple users on multiple branches in multiple sites.

This functionality Ruled out SVN as a choice

I am a former user of clearcase, which has spoiled me for features, but not price nor speed.

Perforce, on paper a good balance between cost and features. If i was working in a text based language I would be over the moon.

So where to Start:

John's essential Guide

Without this I would have been lost in the weeds for days, Give it a read, Special Thanks to John at Giawerx.

Here is the extra information:

Install the P4 SCC IDE plugin to enable Labview to see Perforce through the advanced interface (The command line implementation is poor). John has done this but doesn't explicitly say so in his guide.

When creating a new, empty Depot, you will need to check the view path, the default settings don't work.

Drive Substitution

My last unresolved challenge (Jump in here if anyone can help):

To combat Laview's(and other compilers) incessant need to crosslink all files with absolute paths, I have got into the practice of substituting the project root to another drive (A: and B: tend to be unused now days).

This works seamlessly with clearcase. I haven't yet figured out how to do it with perforce.

Perforce tech help recommend adding your substituted drive path to "alt root" but I have been unsuccessful in applying it to my setup.

Stay tuned for a solution, or better still provide one, I will be much appreciative.

Tim L.

I recently stumbled across this

http://code.google.com/hosting/

It is a tool for project hosting. I think this would be a really cool tool to collaborate with customers and other developers.

Does anybody have any experience with Project Hosting? Any recommendations?

Thanks

Dan

I have got the LabVIEW LVCompare.exe working with ClearCase on windows.

This means that you can do LV differencing using the source control integration with LabVIEW or from the ClearCase explore or the tree view.

Would anybody be interested in a step by step guide on how to do this ?

For those in the know you just need to edit the ClearCase map file ( C:\Program Files\Rational\ClearCase\lib\mgrs\map ) and change the compare & xcompare type managers for the correct file type.

z_whole_copy		compare				..\..\bin\cleardiff.exez_whole_copy		xcompare			..\..\bin\cleardiffmrg.exechange to z_whole_copy            compare                     	..\..\..\..\NATION~1\Shared\LABVIE~4\LVCompare.exe z_whole_copy            xcompare                        ..\..\..\..\NATION~1\Shared\LABVIE~4\LVCompare.exe 

but as I said if anybody was interested I could do a step by step guide.

Danny

I wrote a tool that is invoked by my SCC server; when a change is submitted, the server scans any submitted VIs and controls for revision changes and records them into the SCC's change spec. This allows me to track changes at a very atomic level.

But here's the trouble... the code for reading the history WITHOUT opening up VI dependencies only runs in the development environment. So the original EXE script that I wrote to do this doesn't work.

OK. I'll just invoke Labview with a command line argument to launch the VI I want and pass in the relevant SCC info. No dice. If LV is already running, the command line arguments are the ORIGINAL ones, not the ones used to call it the second time.

So what I have is a LV EXE that is invoked by the SCC. It calls my revision tool via VI server. This works, as long as LV is running. (I suppose I could start and stop LV, but I don't want to deal with that latency every time I submit- which can be often).

So now I have LV running 24/7 on my windows machine (windows 7 pro, no server). Is there a way to run the Dev environment as a service so that it's not running in the UI?

Any other ideas?

Thanks!

I have been debating on how to setup the workspace for a development machine and finally decided on having my workspace be the entire C:\.

This seemed to be the only solution to include <instr> and <vi> directory dependencies in the SCC.

I am struggling to understand how to include all my dependencies without moving files in and out of a smaller-scope workspace.

My gut feeling is that having my C:\ as a workspace will come back to bite me. Has anyone else done this?

I have used SVN in the past, so my hesitation comes from my SVN experience and now using a new SCC (Perforce).

Thanks!

Pete

1) I intend to download and install TortoiseSVN on my PC from http://tortoisesvn.tigris.org/

It’s described as “A SubVersion client, implemented as a windows shell extension.”

2) I presume that TortoiseSVN requires a SubVersion server set up. So, I nintend to doswnload the SubVersion server from http://subversion.apache.org/ Having taken a quick look at the FAQ it says “If you want to host a networked repository, then you need to set up either Apache2 or an "svnserve" server.”. So I intend to do that on a server PC that our development group can all access. Has anybody done this?

3) For the time being I intend not to use a plugin so that the repository can be accessed via LV project. Perhaps I may try out the demo of the JKI plugin as it seems to have much better reports than the PushOK one.

4) I realise there is a lot to set up after this and a lot to learn in the way that the tool is used but for the moment I’d like to get to point where it can be tried out.

Does that look like a sensible start?

My old approach (using SVN) was to have the user.lib under SVN. This was ok as I was the only developer accessing this reusable library. Now I would like to share it with others in my team (using OGPB and VIPM community). Also this became a bit difficult as I started using other locations as well (instr.lib, plugins, tools...).

So I was thinking about having the code-base seperate. Primary code would reside in a dedicated reuse-project folder (managed by Hg). Then I'd create packages using OGPB. These packages can now go onto a server for team-sharing. I as well as others would then install the packages in the user.lib and other places using VIPM community.

So here would be the first question:

? How to track the version on a project basis ?

I've been playing with the subrepositories feature in mercurial (this is suggested as analog to SVN-externals). But that would only allow the files to stay in the project folder, not in user.lib.

The same issue with this use-case:

? How to get reusable checked out on the USB thumbdrive ?

I found that Hg makes life easy there, as I can clone my repository for field-testing on customers side. If I install mercurial on the machine, I even can get the changes committed and back in the home-base, I just push what I've done to my developement machine.

But I not really want to install VIPM (and LV2009RT) on the customer machine and have my reuse code deployed there. It's more effort than I save by having all nice palettes.

This is also a problem with my current SVN approach. But here I did use source distributions with OGB and had a tool to check them back in the project folder.

For both issues, I was thinking of a tool that would just pack all VIs that do not reside in the project folder and maintain a flat copy (e.g. zip archive) in the project folder. But this of course leads to relinking problems (which is generating a lot of changesets in the SCC).

Another idea would be some kind of dynamically linking of the LV-IDE locations (user.lib and palette; instr.lib) to the project dir's, if possible. That would allow for subrepositories (and in this case I'd distribute via Hg instead of VIPM).

Felix

I have try to use it with tortoise , but get below error (sorry in french).

"Une erreur est survenue lors de l'exécution de LVCompare.

Nœud de méthode dans LVCompare.vi

<APPEND>

Nom de la méthode : <b>User Interaction:Compare VIs</b>"

Eric

skipSVNFolders=true

This will cause LabVIEW to skip over your .svn folders when doing a mass compile.

With Regards

Rajkumar

this will solve a lot of Problems using svn (or other scc systems):

http://zone.ni.com/r..._compiled_code/

Greeting,

Dan

This may be an obvious/dumb question, but, I am trying to implement some integrated source code control using LabVIEW proffessional. Code control has been separated up until now and causing a night mare.

Any advice, direction and help much appreciated.

Thanks,

Neil.

TortoiseSVN (and probably most other SCC software) will allow you to override the default diff-viewer per file extension or MIME-type, so I was looking for a way to do this is TestStand sequences. I found this snippet in the TestStand help file:

You can also specify which two sequence files to compare using the command-line arguments for the application. You typically use the Differ application to compare TestStand sequence files in source code control. For example:

SeqFileDifferApp.exe "C:\My Documents\File1.seq" "C:\My Documents\File2.seq"

So I plugged in a custom viewer for .seq using the path "C:\Program Files\National Instruments\TestStand 4.2\Bin\SequenceFileDiffer.exe" %base %mine. You'll notice this is a little different than prescribed by the help file - first' date=' the executable name is different and second, there are no quotes around the parameters. For whatever reason, putting quotes around the params broke the paths. Even without quotes, though, it works with fairly long paths (135+ characters) which has spaces in it.

Another plus, IMO, is the diff that pops up isn't the whole sequence editor - just the pane that shows the diff results.

P.S. If you didn't know, TSVN ships with support for diff'ing a whole bunch of MSOffice formats - really handy for comparing documentation revisions!

For the truly lazy, here's a registry file to add the diff for you. Take note, I'm using TestStand 4.2! You'll have to rename it to .reg to merge it.

TortoiseSVN Diff - seq.txt

I have the opinion that compiled code should not be inside an SCC, so I think about ignoring the following files:

• built*\
  
• *.ogp
  

Apart from that I think the followin LabVIEW specific files should be ignored:

• *.lvlps
  
• *.aliases
  

Any other opinions/ideas?

Ton

Does the NI_Merge program function appropriately for large labVIEW files?

Does anyone have horror or success stories?

Any advice or experiences would be a great help.

Thanks.

However, currently we are using the locking functionality only.

When trying to implement the merge function, IE accessing files without locking, we cannot save even to local copies.

Does anyone know why this is?

Even if I have a local copy of a folder, I cannot save to that local copy.

It must have something to do with locking settings, but I can't find any kind of menu to alter these settings.

How do you set the svn:needs-lock properties for use in a Lock/Unlock model in TortoiseSVN?

Thanks

Dan

When I setup SCC, I have to choose something for this field. The dialog that appears has a disabled OK button until I choose a sub folder of my Perforce Depot. If I select a folder, I get error -2915. If instead I continue to expand the tree until I see a file and then select that, it is happy.

I just wish I understood what was going on here.

Thanks for any help!

-John

(using LabVIEW 8.6.1 and the latest version of Perforce P4V on Windows XP)

I wondering how everyone organizes their Subversion repository with regard to LabVIEW upgrades (e.g. 7.1, 8,2 8.6, 2009, etc). Is it better to create a new repository for each version of LabVIEW (so you don't accidentally recompile a previous version), or have one repository and create new folders for each version.

Example 1: A single repository

Main Repository

• LV7.1
  
  • app1
    app2
    app3
    

• LV8.6
  
  • app1
    app2
    app3
    

• LV9.0
  
  • app1
    app2
    app3
    

Example 2: Multiple repositories for each LabVIEW version

• LV7.1 Repository
  
  • app1
    app2
    app3
    

• LV8.6 Repository
  
  • app1
    app2
    app3
    

• LV9.0 Repository
  
  • app1
    app2
    app3
    

This is just a simplified representation, of coarse there are other organizational details such as branch/tag/trunk.

Thanks for the feed back

I just upgraded from P4Win to P4V and I can’t seem to figure out how to perform a large submit operation.

For example:

If I have 100 files checked out, but I have only changed 17 of them, I need to know which ones those are so I can submit the changes.

In P4Win, I could setup a submit that would only select the 17 files out of the 100 in the checklist that were different from the depot. I could also have it re-checkout the files after submitting and leave the other unchanged files alone.

I could also choose to submit a subset of the 17 changes files if I wanted to have different comments attached to different groups of files.

In P4V I cannot find a way to have it show me which files have been changed. It select every file that is checked out when I choose to submit. It can be set to not submit unchanged files and to re-checkout after submit, but I still need to know what the changed files are before submitting so I can enter the appropriate comments.

I don't to want to revert the unchanged files. Due to how LabVIEW seems to like to recompile VIs at will, I tend to keep everything checked out all the time so I don't have to keep checking things out continuously as I make edits.

Any ideas or help would be greatly appreciated.

-John

We set up an SVN repository on our server a while back and have been using it fine. We use SVNserve on the server so that to access the repository we use svn:\\SERVER\repository\blah. My problem is that we have just installed a new server and want to move the repository onto that.

My initial plan had been to get all users (actually there are only 2 of us) to fully commit all changes, then use hotcopy to move the repository to the new server and setup svnserve on that. The problem is that I've been away and we can no longer access the old server (due to network issues). So I can no longer get to the repository to commit the changes which currently exist "in the wild".

My new plan then was to move the repository anyway (using hotcopy), and then somehow update the local clients to look to the new repository location when updating and committing. But I can't see how to update where the repository is on the local machines. So any attempt to "update" simply fails as is says the repository is no longer there.

Anyone know how best to deal with this?

Cheers

Paul

http://labviewwiki.o...ng_capabilities

Is there a good way to handle project DLLs in a source control environment?

Thanks,

Matt K.

I have been using P4 with LV since 2000. I have never liked the NI P4 SCC plugin, and so a few years ago I created a few tools that ran via menuLaunchVI that did the simple things (login, open, add, etc) but then a couple others that were more advanced...

-Open all callers (Mostly for updating typedefs)

-Add heirarchy

-Rename in P4 and LV

I updated them for the 8.x environment, but I lost some funtionality that I have been too busy to fix. (At one point, they ran great on all Win/Mac/Linux)

However, today I coded up a utility that grabs all the VIs in a changelist, reads their revision histories (since their last submission) and tabulates that back into the P4 Changelist...

QUOTE

-->zjp4_MergeRevisionChangesIntoChangelistDesc.vi

Perforce Action: edit

Rev 17 2009/06/05 13:06:34; Added std out and std err from the p4 change call as outputs

-->zjp4_appendDescriptionToChangelist.vi

Perforce Action: add

Rev 6 2009/06/05 13:06:00; Added std out and std err as outputs

Rev 5 2009/06/05 12:36:33; Working!

Although it annoys most people, I keep the "prompt for comment when saved" option on, and I find it easy to keep much finer notes there, and now they are propagated up to the CL description. I should have done this years ago, as now my CLs (especially for deep, wide changes) will be more accurate.

However, my tools are a bit clunky. seeing as how I keep patching them with every p4 and LV release.

So...

-Does anyone else have their own tools that they would be interested in sharing?

-Would anyone be interested in creating an openG project? I would like to plug them into the JKI right click framework (although they don't have scripting, their program could connect right-clicks and hotkeys to them)

Let me know!

Jed

We're a small company doing a mixture of things, and we use labview to write control software for various automated systems that we supply to our customers. I'm actually relatively new to the company (but have labview experience from my PhD), but I know that source code control has often been mentioned, but never implemented (and, from the stories of my colleagues, it probably should have been!). One of the reasons for this is that, prior to my joining, there has only been one "major" labview application and it was maintained by only two staff members. Now I've joined the team there are 3 of us able to use labview, and we're about to embark on a complete overhaul of that one major application (a complete bottom up re-write of the architecture and a major cleanup of most of the processing algorithms and things that went with it). So, again the topic of source code control has come up. None of us has used it before (at least with labview) although we're familiar with the basic concept, and we don't know where to start - particularly in terms of what software we need. Bearing in mind we're a small team (and from within a small company), we don't want to be spending thousands on licensing of some super dooper massively complex system. What we need is something that prevents "code collisions", probably through checking in and out of code etc and maintains a decent backup of the projects code repository and revision history etc.

Can anyone point me in the direction of where to start? Or recommend a suitable piece of software and how to go about starting it up? If we're going to implement source control, ideally I want it in there from the get go on this project, but we do have a pretty tight timeline so I can't spend months learning a whole new thing just to get this implemented...

Anyway, as I say, if anyone can point me in a useful direction to get us going I'd really appreciate it!

Thanks in advance for any help!

Paul

Can anyone confirm or dispute this claim? The only difference I see is that svn checkout requires an explicit URL?

I am in a situation where I would like TestStand to pull the latest files from a subversion repository before each test begins. If calling svn checkout will not cause any problems then it greatly reduces the code I have to write. I can do one simple "checkout" which will either checkout or update depending on the state of the build tree (I don't have to try to figure out if a working copy already exists).

Thanks,

Toby