Leaderboard

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

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).

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.

That should cause a broken arrow. I vote for bug.

Thanks, all, for supporting the show! It was lots of fun working with Darren and Chris's Beard and Chris for this pilot episode. We'll soon post details on February's show.