Jump to content

Configuring Git to work with LVCompare and LVMerge


Recommended Posts

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.  

 

 

 

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.

 

I'm not sure I understand the entire problem here. You may have to consider different file types differently. As long as you do not have any VI open, even if your project is loaded, just changing the VI on disk shouldn't cause troubles with LabVIEW remembering any old VI code. This assumes that the VI names and/or path don't change. You should be able to simply do a revert or branch without any strange influences. When you then open the main or any other VI from the project you should be fine.

 

If names and or paths change, things get more complicated. But assuming that the GIT repository state was consistent at the moment the reverted or branched situation was taken as far as LabVIEW is concerned, this would also mean that the lvproj file and lvlib files have changed, because these are were the actual paths are recorded for management reasons. So if your GIT operation changes any of these files then yes you will have to find a way to reload the project and/or libraries that are affected.

 

So if you have a way to determine that such files have changed you could attempt to do a smart reloading. Otherwise it would seem the safest option to reload the entire project every time you do an action that could potentially change the project and/or library files under the nose of LabVIEW.

Link to comment
  • 2 weeks later...

Thanks Rolf,  i was initially confused how labview loaded things into memory but your description makes sense compared to my testing.

 

 I think where things get complicated is when your are performing actions on classes or libraries.  My current plan is to smart reload if the user chooses to perform an action on one of these items.  I'm also debating if i should force close the VI if i should present a save option/force close if the vi is currently open when the action is performed.  

Link to comment
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")

 

Hey, I'm trying to get this set up. Have copied your code across with the appropriate modifications to the paths. How do you actually configure sourcetree so that it calls the external diff tool? i.e. do you leave it calling the system diff, or write a command into the custom call part?

Link to comment
Hey, I'm trying to get this set up. Have copied your code across with the appropriate modifications to the paths. How do you actually configure sourcetree so that it calls the external diff tool? i.e. do you leave it calling the system diff, or write a command into the custom call part?

 

Here is how I have this set up.  Select Tools...Options... and click on the Diff tab.

In the External Diff/Merge area I have

External Diff Tool: Custom

Diff Command: 'C:/Users/Paul/AppData/Local/Programs/Git/bin/_LVCompareWrapper.sh'

Arguments:   "$REMOTE" "$LOCAL"

Link to comment
  • 2 weeks later...

Hello all,

 

I had a play and managed to figure out how to launch LVMerge based on the previous scripts in this thread.


This is the bash script I use:

#!/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 LVMerge.exe does not.abspath () {	(		DIR=$(dirname "$1")		FN=$(basename "$1")		cd "$DIR"		printf "%s/%s" "$(pwd -W)" "$FN" | tr '/' ''	)}lvmerge="C:Program FilesNational InstrumentsSharedLabVIEW MergeLVMerge.exe"remote=$(abspath "$1")local=$(abspath "$2")merged=$(abspath "$3")base=$(abspath "$4")echo Launching "$lvmerge"exec "$lvmerge" "$base" "$remote" "$local" "$merged"

 

The relevant section of my global .gitconfig file is configure as follows:

[merge "lvmerge"]    command = lvmergewrapper.sh "$LOCAL" "$REMOTE" "$MERGED" "$BASE"[mergetool "sourcetree"]	cmd = 'C:/GitRepositories/lvmergewrapper.sh' $REMOTE $LOCAL $MERGED $BASE	trustExitCode = true

And finally, in sourcetree the options menu under the diff tab is set to Custom with

Diff Command: C:/GitRepositories/lvmergewrapper.sh and

Arguments: "$REMOTE" "$LOCAL" "$MERGED" "$BASE"

 

I'm not sure exactly what trustExitCode = true does, but I did notice that choosing "No" in the accept merge dialog of the LVMerge tool results in the .git lock file not being cleared and consequently I couldn't do any git operations without first deleting that file. It may be the case that trustExitCode should be set to false. If anyone feels inclined to map this behaviour out, I'd love to hear back. I'm sure I'll probably stumble across the right way to do it eventually but hey.

 

Cheers,

Alex


Edit: I'm not sure if some parts of the .gitconfig file are redundant in that they are only relevant to calling it from the commandline? Really not sure, but it seems to work this way (Hopefully it doesn't twist up which ones are remote and which ones are local).

Edited by AlexA
  • Like 1
Link to comment
  • 6 months later...

Has anyone tried this on linux so far? I gave a shot to it and stumbled into the following:

  1. LVCompare opens a new session of LV at each call. I presume that it is screaming for me to change labview to labview -launch in the couple of relevant places within the script. Btw the mechanics of /usr/local/natinst/lvcompare/LVcompare involves creating a file /tmp/LVCompare.ini which contains the absolute pathnames of the files to be diffed and the comparison flags, which the closed vi /usr/local/natinst/lvcompare/supportVIs/_prolvcmp.llb/LVCompare.vi subsequently erases; however there seems to be no problem as long as calls from an external script are correctly sequenced and the files to be diffed survive until termination of LVCompare. I anticipate a problem if more that one file couple is compared at a time.
  2. Integration with common git GUIs. I've randomly tried in qgit (the one I use daily), gitk, gitg, git-cola, giggle. In none I could get diffing work nicely if at all. Common issues are: a) an external diff program can be configured, but inflexibly for all file types; b) the temporary files to be diffed are nevertheless treated as text, truncated at the first \n, and useless to LVCompare. What instead turns to be a non-issue, is absolute pathnames, because these guis pass it nicely to the configured differ.

That doesn't mean that I might not try harder in future, studying harder the options of git config, or writing a diff script which calls either meld or LVCompare depending on the file extension, for perusal of the only GUIs which treat binaries as binaries, but for the moment my motivation is low -- unless someone has already a ready solution to share.

Link to comment
  • 7 months later...

The examples didn't work exactly as-is for me.  I had to make some modifications and wanted to share them on this thread.  The script modifications allow for LVCompare.exe to work on 32-bit and 64-bit Windows systems, however it has not been tested on a 64-bit system yet.

 

To use this with Atlassian SourceTree, modify your .gitconfig file to include:

[diff]
tool = "sourcetree"
[difftool "sourcetree"]
cmd = ''C:/<INSERT PATH TO SCRIPT HERE>/_LVCompareWrapper.sh'' "$REMOTE" "$LOCAL"

where <INSERT PATH TO SCRIPT HERE> can be wherever you decide to save the shell (.sh) file.

 
 
Here is the contents of the "_LVCompareWrapper.sh" file
#!/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"
    echo -n "$(pwd -W)/$FN" | tr '/' '\\' 
    )
}

lvcompareNormalLocation="C:/Program Files/National Instruments/Shared/LabVIEW Compare/LVCompare.exe"
lvcompare64bitWin32bitLV="C:/Program Files (x86)/National Instruments/Shared/LabVIEW Compare/LVCompare.exe"

if [ -e "$lvcompareNormalLocation" ]; then
    lvcompare="$lvcompareNormalLocation"
elif [ -e "$lvcompare64bitWin32bitLV" ]; then
    lvcompare="$lvcompare64bitWin32bitLV"
else
    echo "LVCompare not found!"
    exit
fi

#echo "Using $lvcompare"

local=$(abspath "$2")
remote=$(abspath "$1")
echo Launching "$lvcompare"
#echo Launching "$lvcompare" -nobdpos -nofppos "$local" "$remote"
exec "$lvcompare" -nobdpos -nofppos "$local" "$remote"
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.