Configuring Git to work with LVCompare and LVMerge

[PaulL]

Has anyone actually configured Git to work with LVCompare or LVMerge?  (I've seen some threads on various boards saying it "should be something like" <x>, but it isn't quite <x> and I haven't found anywhere that someone has actually described it successfully.)

 

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?]

[GregFreeman]

I got about as far as you as well, but couldn't really get things to work. Below are some relevant posts which you may have seen already. I can tell you what I've been doing, which is a bit tedious but has worked ok. I could see it becoming more of a problem if there were lots of changes made, but we have been trying to commit and sync up frequently so that things aren't too out of whack. Sometimes it's enough for me to just visually look at the before and after (selecting them from within Source Tree) and tweak what I need to in my copy, then choose mine to resolve the conflict. One drawback here is dependencies of the remote copy of the VI will be missing, Another thing I have done is cloned the repo twice on disk. I think this is essentially what the first like I posted does for you, but I'm not positive. I checkout the base branch in one clone, and my feature branch in the other. I then do a diff on the conflicting files, resolve diffs on disk in my feature branch copy, then select my copy in Source Tree to resolve the conflict. I should also note something that has caused some headache a couple times is that if you rebase, the first thing it does is checkout the base branch. So, when resolving conflicts, "theirs" is actually your feature branch copy, because the branch you have checked out has changed somewhat unbeknownst to you as part of the rebase. Anyways, I know this doesn't answer your question directly, but maybe these things provide a bit of a work around. At first I was a bit wary of DVCS, honestly, but now that I have played around with git and am becoming more comfortable with it, I must admit I really quite like it. Off topic, but let me know if at any point you would like to compare workflows and what has worked for us/you guys. I know we've touched on this before in another thread, but now that I am more familiar I have more ability to contribute.

 

https://github.com/joerg/LabViewGitEnv

 

https://decibel.ni.com/content/groups/git-user-group/blog/2013/02/19/git-and-labview-merging

Edited January 30, 2014 by for(imstuck)

[JackDunaway]

Paul, Greg, others reading along -- I have a few meta questions on this topic:

1. How often do you find yourselves wanting to invoke a Compare?
2. How often for a Merge?
3. After using those tools, are you happy with the results, and/or get the job done you set out to accomplish?
   

[GregFreeman]

Paul, Greg, others reading along -- I have a few meta questions on this topic:

1. How often do you find yourselves wanting to invoke a Compare?
   
2. How often for a Merge?
   
3. After using those tools, are you happy with the results, and/or get the job done you set out to accomplish?
   

 

1) TL;DR - Only once per week or so; < 5 VIs conflicting, usually.

Not as often as you may think (or at least not as often as I thought) when I started using DVCS with LabVIEW. I am sure separating source from compiled alleviates some of these issues. Also, we try to delegate "actors" to different developers, and avoid static dependencies from within actors (i.e. send data to a mediator, not directly to another actor). This ensures the processes don't touch each other. The problem arise more when two actors contain the same class within, that both developers may need to modify. Even so, I'd say on average I run into conflicts once a week, with no more than 4 or 5 VIs in that conflict. The only thing that is a bit of a pain is in order to keep things in sync, we find ourselves merging feature branches back into the develop branch quite a bit so everyone can pull changes into their local develop branch and rebase/merge their feature branches. We do these merges into develop even when a feature isn't complete. By merging feature branches into develop more frequently, and updating local feature branches via rebasing on, or merging in these commits from develop, it helps limit the number of changes per commit. Therefore, it limits the number of potential conflicts. But, it certainly clutters up the repo by merging in the same feature branch multiple times instead of once when completed. I could see myself running into wanting to diff more often if we truly followed a model where feature branches weren't merged into develop until fully complete. Note: This may also imply our feature branch scope is too large, but the two things are not mutually exclusive. We're working on it. If anyone has questions/comments on that workflow let me know.

 

2)Merge - about as often as a compare -- maybe a bit less. Sometimes a compare reveals I can just select one file over the other to resolve the conflict, no harm done.

 

3)In my opinion, diff is a difficult thing to solve in a graphical language, and others may not agree but I find the diff tool pretty decent. Sure, sometimes there are things that aren't represented well (such as when a case has been deleted from a case structure) but it does an OK enough job that my mind can fill in the gaps. YMMV and opinions may differ greatly. I haven't used the diff tool a whole lot, so someone with more experience may be able to provide better feedback here. I think it's the merge tool that opens like 3 windows inside one with splitter bars dividing them or something? I may be wrong here. I've only used it one time at a customer using Mercurial a few months ago so hopefully I'm referencing the correct thing. I found it terribly hard to navigate around the windows etc. I think this tool has bigger issues than the diff tool. It certainly resulted in more 

 

Hope that provided you, generally, with what you wanted to know.

Edited January 30, 2014 by GregFreeman

[PaulL]

As far as resolving the issue on this thread goes, I did get further in that I was able to get LVCompare to start (not difficult once I figured it out), but I encountered a problem with malformed paths passed as parameters to LVCompare.  I documented this in a discussion on Atlassian Answers (https://answers.atlassian.com/questions/254737/sourcetree-external-diff-path-issue-on-windows).  When no one commented on that thread, I started a support case with Atlassian.  Much to their credit, Atlassian's support responded promptly.  At the support person's request, I verified that I can get LVCompare to work with test VIs in a text project.  I'll update this thread once I know more....

 

After I started this thread I did discover for myself the {Open 'Before'}  and {Open 'After'} buttons in SourceTree, to which Greg refers in comment #2 above.  These are quick and easy to use to open VIs to compare (although we don't have the cool features that automatically highlight the differences).  It has been helpful in my tests so far.

 

1)  I have used LabVIEW's diff capability on occasion in the past with TortoiseSVN.  Within limits (there is the problem Greg noted above if the hierarchy has changed) the results are good, although the process could take some time to complete.

2) I've done merges to see what happens, but in the end on the rare occasions where I really wanted to merge code files I ended up doing this manually rather than configure and trust the merge tool.

3) The merge tool has a problem in that the number of required inputs isn't suitable for all use cases.  On the other hand, both tools do a reasonable job (and are really pretty cool) if you go through the trouble of setting them up correctly and going through the pain (unavoidable?) of patiently using them.

In my previous project we avoided the issue by maintaining a single development trunk (no branches whatsoever) and carefully managing development so merges were unnecessary.  That worked well for that project, but it isn't appropriate for my new project, where branches will, I expect, be common, due to the nature of the product releases, the version control system (Git, which is a Distributed Version Control System), and the process we plan to use (GitFlow Workflow looks to me like the way to go).  I'm trying to ensure we will be able to do merges when we need them, which I expect we will need to do regularly (even if we just merge branches, manually resolving any differences in individual files).

I actually like Git and the DVCS approach for the most part.  One big difference is that in Subversion we had all the files ultimately in one repository.  That doesn't fit the Git paradigm, but it does beg the question of how to maintain the path (and version) relationships between components.  Right now I think we will handle this by convention or with an external tool (Fusion, Stash, if it does this, or maybe VIPM can help).

[GregFreeman]

Paul, I have a follow up here that I wanted to post. I just got done doing a Merge with a few different conflicting files, and I was able to do it successfully, without the merge tool or diff tool integrated directly into source tree. I spent time yesterday trying to get things to work with source tree but was unable to successfully do so. However, I got close, so I may hack away at it more later. 

 

I basically did what I mentioned the other day with opening the before and after, but wanted to get into a little more detail. Our company is currently using git flow within source tree, or a loose version of it anyways. I don't always use the gitflow button when finishing things up, but usually do to start features, releases, etc. This is mainly because I want more fine grained control when finishing a feature versus starting one just because I see more potential for issues when bringing code together versus branching off from existing, up to date code. This may be me worrying too much, but for now it seems to work. 

 

So, here is how I handled things. My feature wasn't done but the develop branch had changes made to it which I wanted to incorporate into my feature branch to keep everything relatively in sync. After all, the longer you wait to merge, the more issues you will run into. However, I really didn't like the idea of merging develop into feature, because I thought it may be easy to overlook or misunderstand my coworkers changes should I have to pull them into my copy. Therefore, I felt it was better for me to merge my feature branch into develop and move my changes into develop's copy of the file. So, I checked out develop and selected to merge feature into develop. On conflicting files, I used open before and open after to open both, then ran LVCompare on them, moving my changes into the develop branch's copy of the file. I saved the file, then resolved using the develop branch's copy ("mine"). 

 

One this was done, I committed the changes. Now, develop was one commit ahead of my feature branch. But, because my changes from my feature were already applied in the develop branch (from my diff and merge), now I could just merge from develop back into my feature branch (which should work seemlessly, with no conflicts). Now both my feature branch and develop branch are pointing at the same commit, and I can continue working on my feature branch which has both its changes, and develop branch's changes.

 

Does this make sense?

Edited February 18, 2014 by GregFreeman

[PaulL]

Greg,

 

I'm not sure I will be much help on this.  I think you are actually a little ahead of me a the moment on GitFlow workflows.  That is the direction in which I want to go, but I haven't used that in an actual project yet.  I haven't used the Git Flow button in SourceTree.

 

I understand what you did, but I'm not following why you didn't merge develop into feature.  You may be onto something (it's the key point!), but I'm not following.

 

__

By the way, on the difftool issue in this thread, I have verified that I can call LVCompare.exe with filepath parameters from the Windows command prompt (not connected to any kind of version control) successfully.  With Git I can set up the .gitconfig file so that calling 'difftool' does summon LVCompare.exe, but the remote path Git passes to LVCompare is malformed (the path starts out C:/).  (That is a backslash followed by a forward slash.)  I started a discussion on Atlassian's forum (https://answers.atlassian.com/questions/254737/sourcetree-external-diff-path-issue-on-windows?page=1#comment-263644) and opened a support case with Atlassian (https://support.atlassian.com/servicedesk/customer/stsp/problem-report-956), but I have since reproduced the behavior using Git directly (difftool) so I started a case with Git directly.  (I'm not sure this will go anywhere, since I have yet to receive even an acknowledgment to the issue request, which I submitted through e-mail.  I had to send the e-mail three times.  The first time it was automatically rejected because I was greylisted because they hadn't received an e-mail from me before, and the second time it was rejected because it supposedly had HTML in it--maybe in the headers?  I then sent a plain text version, and nothing happened, so I am good?  This is not a great system to make a great product.)  At this point I'm pretty sure it's a Git bug (and a bad one!).  I think it is possible to work around this using a batch file, but I'd rather fix the bug.

 

Paul

[GregFreeman]

Paul, no problem we can catch up on this later. That said, do not fully take my advice because I just noticed some changes missing from my merge. I think I resolved some conflicts incorrectly   . Part of the learning process!

 

Also, with regards to the path, the way I was getting around this (although i still didn't get things to fully work) is write a shell script that formats the path correctly, and that script was invoked upon calling of the difftool. If you are still playing around with this, maybe I can send to you what I have as a starting point.

 

Edit: figured out where I went wrong with my merge conflict resolution. Resolve using Mine/Theirs did not do what I thought. It didn't use my working copy, which is the one I made changes to during the diff. I should have staged my working directory file in source tree and resolved the conflict with that (not mine, or theirs). I'm going to stop flooding this thread though, as I have somewhat gotten it off track from the original question. That said, Paul, are you going to be at the CLA Summit? I'd love to take some time to sit down and talk about these workflow things, and other trials and troubles we have come across, to help prevent potential future issues. 

Edited February 19, 2014 by GregFreeman

[PaulL]

Greg, I would indeed by interested in how you put together your batch file.  I would indeed enjoy discussing these and other issues with you and other interested parties at some event, perhaps NI Week or a virtual event.

[GregFreeman]

Greg, I would indeed by interested in how you put together your batch file.  I would indeed enjoy discussing these and other issues with you and other interested parties at some event, perhaps NI Week or a virtual event.

 Let me take the weekend to gather what I have and jog my memory so I can explain how I got to the point I am at. 

[Omar Mussa]

Greg,

 

I'll be at the CLA summit and have been using Git and would like to chat with you about how you're using GitFlow ...  I plan to use GitFlow on my next project which is starting soon.  Would like to try to sync up there.

 

Thanks in advance!

[GregFreeman]

Greg,

 

I'll be at the CLA summit and have been using Git and would like to chat with you about how you're using GitFlow ...  I plan to use GitFlow on my next project which is starting soon.  Would like to try to sync up there.

 

Thanks in advance!

 

Definitely. Let's chat. I'll seek you out once I have a better idea of my schedule. Check your PM's, I'll send you my email address.

[PaulL]

Success!

 

OK, it seems this is a problem with MSys or MSysGit mangling the Windows paths.  Our local Git guru, with background input from Git support and my tests, helped me write a shell script to do two things:
1) Return the Windows absolute paths.
2) Convert the forward slashes to back slashes.

Here are the details on _LVCompareWrapper.sh:
File location: On my machine, this file is in the C:UsersPaulAppDataLocalProgramsGitbin directory.

The actual filename does not matter, as long as the configuration item in the .gitconfig file points to it.

The file contents are presently:

#!/bin/bash

# Method to determine absolute path
# The -W parameter on the pwd command is necessary to return the Windows version of the path.
# Not using the -W parameter will result in a conversion of temp directory to a 'tmp' path meaningful only in the Linux #

environment.
# Piping the result through tr '/' '' translates the forward slashes to backslashes.
# Windows understands forward slashes, but LVCompare.exe does not.

abspath () {
  (
  DIR=$(dirname "$1")
  FN=$(basename "$1")
  cd "$DIR"
  printf "%s/%s" "$(pwd -W)" "$FN" | tr '/' ''
  )
}

lvcompare="C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe"
local=$(abspath "$1")
remote=$(abspath "$2")
exec "$lvcompare" -nobdpos -nofppos "$local" "$remote"
# For the options, see http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/configlvcomp_thirdparty/.

Of course we need to modify the global .gitconfig file, too.  Here are the details:

This is the global .gitconfig file.  On my machine this resides in the C:UsersPaul directory.

 

The relevant part of the file (set up to work with SourceTree, but it is possible to use another tool or to use the wrapper tool via the git difftool command) presently is:

[diff]
  tool = "sourcetree"
[difftool "sourcetree"]
  cmd = ''C:/Users/Paul/AppData/Local/Programs/Git/bin/_LVCompareWrapper.sh'' "$REMOTE" "$LOCAL"
  # Note that the parameters are actually passed in reverse order to the wrapper.

The parameter reversal does seem to me to be a bug in SourceTree.

Paul
 

[PaulL]

A further note on the parameter reversal:

 

Note that If I switch the order of the parameters the results are flipped (but still mismatched).

I actually now think this is a problem on the Git side, since I see the issue if I call git difftool directly.  It's hard to believe, though, since the distinction between local and remote is quite essential for Git to work (although maybe not so much for difftool).  Still, when I run git difftool, clearly the local parameter returns the remote path, and vice versa.  Quite puzzling indeed!

Paul

[PaulL]

Atlassian support and Git support have both pointed out that local and remote are consistent with the definition in the manual for difftool http://git-scm.com/docs/git-difftool.html.

So, what we have is, in the global .gitconfig file:
[diff]
tool = "sourcetree"
[difftool "sourcetree"]

cmd = ''C:/Users/Paul/AppData/Local/Programs/Git/bin/_LVCompareWrapper.sh'' "$REMOTE" "$LOCAL"

The associated wrapper script contents are:

#!/bin/bash

# Method to determine absolute path
# The -W parameter on the pwd command is necessary to return the Windows version of the path.
# Not using the -W parameter will result in a conversion of temp directory to a 'tmp' path meaningful only in the Linux # environment.
# Piping the result through tr '/' '' translates the forward slashes to backslashes.
# Windows understands forward slashes, but LVCompare.exe does not.

abspath () {
(
DIR=$(dirname "$1")
FN=$(basename "$1")
cd "$DIR"
printf "%s/%s" "$(pwd -W)" "$FN" | tr '/' ''
)
}

lvcompare="C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe"
local=$(abspath "$1")

[ThomasGutzler]

If anyone is wondering how to get "git diff" working from the git bash, here's what I came up with:

1. Configure a different diff method for *.vi and *.ctl
   To do that, we add the following to .gitattributes (or .git/info/attributes or your global gitattributes file)
   *.vi diff=lvdiff
   *.ctl diff=lvdiff
2. Define what git should do for those files
   

   $ git config --global diff.lvdiff.command 'lvcomparewrapper.sh "$LOCAL" "$REMOTE"'

    
3. Put lvcomparewrapper.sh somwhere in the $PATH ($ echo $PATH) (or modify above command to an absolute call)
   I had to slightly modify the wrapper script to this:
   

   #!/bin/bash# Method to determine absolute path# The -W parameter on the pwd command is necessary to return the Windows version of the path.# Not using the -W parameter will result in a conversion of temp directory to a 'tmp' path meaningful only in the Linux # environment.# Piping the result through tr '/' '' translates the forward slashes to backslashes.# Windows understands forward slashes, but LVCompare.exe does not.abspath () {	(		DIR=$(dirname "$1")		FN=$(basename "$1")		cd "$DIR"		printf "%s/%s" "$(pwd -W)" "$FN" | tr '/' ''	)}lvcompare="C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe"local=$(abspath "$4")remote=$(abspath "$3")echo Launching "$lvcompare"#echo Launching "$lvcompare" -nobdpos -nofppos "$local" "$remote"exec "$lvcompare" -nobdpos -nofppos "$local" "$remote"

    
   

Now you're all set up to use the good old command line:

 

$ git diff Main.viLaunching C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe

 

 

[odoylerules]

I'm sure you all are aware of it, but there is a TortoiseGit option as well.  It allows you to configure LVMerge/LVCompare exactly like TortoiseSVN and has the same windows integration.  

 

https://code.google.com/p/tortoisegit/

 

 

I personally just switched from SVN to Git source control and so far i like it much better.  The ability to branch so easily is great for test code.  The only issue is that you typically have to reload a project after a branch switch but this is a Labview issue not source control.  I tried the Atlassian windows options since i also host code on bitbucket, but i found it too heavy and the TortoiseGit option was more familiar since i was coming from SVN.

 

I'm actually getting ready to start work on a TortoiseGit project provider for integrating Git into the project window similar to the current SVN options.  i'll post it in this forum once it gets further along.  

[MikaelH]

TortoiseXXX is great, but which one should I use today :-)

[kapurm]

It seems we have mostly Git Bash users here.

 

We use TortoiseGit & LabVIEW (2013). We setup TortoiseGit with LV Merge as shown below but could not get it to work
https://www.labviewhacker.com/doku.php?id=templates:software:tortoisegit:setup_lvmerge

Q. We have several developers working on a project at a time and hence have the need to merge branches. Has anyone been able to successfully use the Merge in TortoiseGit? If yes, we will appreciate the sequence for LabVIEW.

 

We got LVCompare to work with TortoiseGit. One suggestion is to view this video (watch from 19:50)

Edited May 30, 2014 by kapurm

[Rolf Kalbermatter]

It seems we have mostly Git Bash users here.

 

We use TortoiseGit & LabVIEW (2013). We setup TortoiseGit with LV Merge as shown below but could not get it to work

https://www.labviewhacker.com/doku.php?id=templates:software:tortoisegit:setup_lvmerge

Q. We have several developers working on a project at a time and hence have the need to merge branches. Has anyone been able to successfully use the Merge in TortoiseGit? If yes, we will appreciate the sequence for LabVIEW.

 

We got LVCompare to work with TortoiseGit. One suggestion is to view this video (watch from 19:50)

 

Well, one big advice: Try to avoid merging as much as possible. Unlike with text sources where there is often automatic merging possible and you only have to glance over it to make sure nothing stupid has been done, graphical merging is still a fully manual job. The merging tool shows you the differences and lets you decide which changes should be copied into the master but it will not do any automatic merging. That alone is a big incentive to only really merge if there is absolutely no other way around it.

 

We have found that it is easier to ensure that no two people are ever working on the same VI to avoid the merging hassles afterwards. Graphical merging is still in its infancy and I'm not even sure there is an easy way to reach the same level of automatic merging than with text sources. Text is fairly one dimensional in structure, while graphics are at least two dimensional and in the case of LabVIEW in fact more like 2 1/2 dimensional.

 

Automatic text merging can still suck too, if two developers happen to make changes to the same text lines, but for LabVIEW merging the smallest unit of measure for automatic merging is still a VI.

[ShaunR]

I have to echo Rolf here.

 

I have never found any source control software to be .adequate for LabVIEW. I just treat them all as backup and restore systems. When working with multiple developers I usually break the project into multiple sub-projects that each developer can own, so to speak. It's just a less granular way of what Rolf is describing. My advice is just avoid merging in LabVIEW altogether.You'll live longer .

Edited May 31, 2014 by ShaunR

[odoylerules]

While agree merging can be pain, i personally find the way labview "loads" files into memory to be the largest issues with using source control within labview.  Unfortunately for labview, if working within a project or library, this means that you must completely reload the project after branching just so that you can reload all the updates VI's into memory.  Maybe i'm missing something but i can not seem to find a way to reload a single VI into memory.

 

 

 I think the main reason that GIT is so popular is that branching is so easy compared to other source control providers.   Being able to branch, test a feature and then merge it back into your current branch is where git shines.  All of those actions are extremely lightweight within the GIT environment.  Its actually forced me to rethink how i treat source control.  Like ShaunR i typically was using SVN as a backup/restore system.  However, since moving to git i find myself branching a lot more.  Like i mentioned, the LV VI in memory issues seems to be the main hiccup for making this process a lot more fluid.

Edited June 1, 2014 by odoylerules

[Rolf Kalbermatter]

While agree merging can be pain, i personally find the way labview "loads" files into memory to be the largest issues with using source control within labview.  Unfortunately for labview, if working within a project or library, this means that you must completely reload the project after branching just so that you can reload all the updates VI's into memory.  Maybe i'm missing something but i can not seem to find a way to reload a single VI into memory.

 

 

 I think the main reason that GIT is so popular is that branching is so easy compared to other source control providers.   Being able to branch, test a feature and then merge it back into your current branch is where git shines.  All of those actions are extremely lightweight within the GIT environment.  Its actually forced me to rethink how i treat source control.  Like ShaunR i typically was using SVN as a backup/restore system.  However, since moving to git i find myself branching a lot more.  Like i mentioned, the LV VI in memory issues seems to be the main hiccup for making this process a lot more fluid.

 

It's more complicated than that. When you only have the project open, no VIs are actually loaded in memory. But the project remembers all the linkage and you get into conflict hell when the location of any of the VIs changed. LabVIEW is in that respect very special as each VI is in fact its own dynamic loadable library module. You get the same DLL hell issue when you deal with multiple DLLs but this is a problem that happens at deployment of the traditional application only, not during development. Basically in conventional programming environments you do not have any dynamically linked modules like in LabVIEW. Each source code file is its own entity only loosely coupled by the name of the symbols and also only at the linker stage. The compiler does not care about if module x uses function z from module y or if that function is rather located in module xyz. Only the linker tries to fit everything together and complains if it can't match a required import to any other export symbol in the combined object files. All source code control is build around this typical scenario, not about a strongly linked system like LabVIEW is using even at development time already.

 

Should LabVIEW adopt a loosely linked scheme like C does? Most likely not. They used to have a much less strict system before projects got introduced. LabVIEW simply matched a VI reference to the very first VI it could find on disk with the required name. That was in several ways easier to deal with than the current project approach that remembers also the exact location of each VI as it was last used and gives you conflicting items if something has changed. Quite a hassle to resolve when you know you moved a VI library on disk for some reasons. However the situation with the less strict system before projects existed caused many headaches and undesired cross linking by not so experienced LabVIEW programmers, and even many experienced LabVIEW progammers run into a mess at some point sooner or later.

 

So the problem here is that LabVIEW has several reasons to do as it does but that all the source code control systems were never really designed to deal with these specific requirements that LabVIEW poses. You could just as much claim that it is the SCC's fault than LabVIEW's but in reality it is neither's fault. LabVIEW has certain requirements born out of of certain expectation in how it was designed to work, at a time SCC was itself in its infancy and CVS was about the highest of the feelings you could get in that area. Requiring LabVIEW to change its paradigmas to work better with modern SCC systems is not really a realistic expectations. At the same time NI is not likely going to develop its own SCC system that is specifically adopted for LabVIEW's quite unique requirements. Bigger fish than NI have failed catastrophally in that area, or is still anyone on this site forced to suffer under Visual Source Safe??

[ThomasGutzler]

Maybe i'm missing something but i can not seem to find a way to reload a single VI into memory.

 

You can always do "File / Revert..." after reverting a single VI (via svn/git/whatnot). If that option is greyed out, just make any change to the VI. This will reload the VI from disk.

This works well if you only reverted a single or very few files because LabVIEW then checks dependencies in both ways. Reverting an entire class somewhere in the middle of the dependency tree will leave you with a 30 minute exercise for your click-finger. Much faster to just kill LabVIEW and load from scratch.

Edited June 1, 2014 by ThomasGutzler

[odoylerules]

Rolf thanks for the summary, this gives me a better picture of whats going.  I don't have much experience with other IDE's outside of labview and webstorm.  I have run into the dependency nightmare you mentioned and it is a huge pain.  

 

You can always do "File / Revert..." after reverting a single VI (via svn/git/whatnot). If that option is greyed out, just make any change to the VI. This will reload the VI from disk.

This works well if you only reverted a single or very few files because LabVIEW then checks dependencies in both ways. Reverting an entire class somewhere in the middle of the dependency tree will leave you with a 30 minute exercise for your click-finger. Much faster to just kill LabVIEW and load from scratch.

 

 

I'll have to give that a shot Thomas.  I need to dig around and see if there is a VI server method for performing this revert.  

The reason i bring all this up is that i am currently in the process of writing an open source project provider for integrating TortoiseGit into the project window.  All the basics are there currently and i'm hoping to release a beta for people to play with shortly.  The long term goal is to bypass TGIT and integrate direct GIT Source Control into LV but since TGIT is already developed its a decent place to start.  

 

Currently i've given the user the ability to reload the project from within the provider and i'm just trying to solidify which actions are going to require a full project reload.  It appears that basically any situation in which you are working within the project window and you need to revert or switch branches the user is going to have to reload the project to accurately see any Source Control changes.  There are a variety of issues with this, such as saving after the switch or revert but those can be overcome with prompts to the user at the right time.

 

Does closing a project, assuming all vi's are within that projects context and are closed, guarantee that all project VI's are unloading from memory?  I'm really hoping a full LV restart is not required every time you need to reload VI's.