![]() ![]() I had a play and managed to figure out how to launch LVMerge based on the previous scripts in this thread. do you leave it calling the system diff, or write a command into the custom call part? How do you actually configure sourcetree so that it calls the external diff tool? i.e. Have copied your code across with the appropriate modifications to the paths. Lvcompare="C:Program Files (x86)National InstrumentsSharedLabVIEW CompareLVCompare.exe" # Windows understands forward slashes, but LVCompare.exe does not. # Piping the result through tr '/' '' translates the forward slashes to backslashes. # Not using the -W parameter will result in a conversion of temp directory to a 'tmp' path meaningful only in the Linux # environment. # The -W parameter on the pwd command is necessary to return the Windows version of the path. The associated wrapper script contents are: gitconfig file:Ĭmd = ''C:/Users/Paul/AppData/Local/Programs/Git/bin/_LVCompareWrapper.sh'' "$REMOTE" "$LOCAL" 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.Ītlassian support and Git support have both pointed out that local and remote are consistent with the definition in the manual for difftool. So if you have a way to determine that such files have changed you could attempt to do a smart reloading. 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. 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. ![]() If names and or paths change, things get more complicated. When you then open the main or any other VI from the project you should be fine. You should be able to simply do a revert or branch without any strange influences. This assumes that the VI names and/or path don't change. 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. You may have to consider different file types differently. I'm not sure I understand the entire problem here. 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.ĭoes 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. 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. 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.Ĭurrently 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. All the basics are there currently and i'm hoping to release a beta for people to play with shortly. 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. I need to dig around and see if there is a VI server method for performing this revert. I have run into the dependency nightmare you mentioned and it is a huge pain. ![]() I don't have much experience with other IDE's outside of labview and webstorm. Rolf thanks for the summary, this gives me a better picture of whats going.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |