"go to first difference" option not working in BC4 when called by TFS

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • davenovak
    Expert
    • May 2008
    • 58

    "go to first difference" option not working in BC4 when called by TFS

    Under Tools --> Options --> Next Difference exists a checkbox for the option When loading new files, go to first difference. With this option enabled, a file compare is supposed to jump to the first difference in the file.

    I am using TFS for Visual Studio 2013 and have the User Tools for Compare and Merge configured exactly as described in http://www.scootersoftware.com/suppo...?zz=kb_vcs#tfs Everything works perfectly fine if using BC3 but the "go to first difference" option does not seem to work in BC4 when the difference is not on the first visible page. Given that things are correct in BC3, I have to think something has changed here in BC4 that is causing this.

    Please note that I am only able to reproduce this issue when BC4 is launched by TFS. When comparing any two files directly (without TFS), I cannot reproduce the issue.
  • Aaron
    Team Scooter
    • Oct 2007
    • 16002

    #2
    Hello,

    Thanks for the report. Configuring BC4 and VS2013 Express with a test TFS, going to the first difference seems to work as expected. Do you have Ignore Unimportant enabled or Visible Whitespace disabled? Is it perhaps going to the first whitespace? You mention that this does not occur if you test with the command line, but if you "Save As" the left and right side from the source control launch (to have local copies of the exact files), then open them from the command line with BComp.exe local1 local2, does the issue reproduce?
    Aaron P Scooter Software

    Comment

    • davenovak
      Expert
      • May 2008
      • 58

      #3
      I normally do not have Ignore Unimportant Differences enabled, but I can guarantee it is not a whitespace issue. I get the same exact behavior whether I have that enabled or not. And again, it all works as expected when using BC3.

      I played around with this some more this morning and uncovered a number of important new clues:
      1. I am unable to reproduce the problem if BC4 is already running (i.e., issue happens only on the first compare that launches BC4)
      2. Using a copy of the exact same problematic files (saved to a tmp directory), I still cannot reproduce this issue if I manually launch BComp.exe local1 local2.
      3. HOWEVER, if one of the two files in the compare belongs to a known TFS source-controlled directory and exists in the TFS repository and is checked out, I can reproduce the issue now even when launching BComp.exe local1 local2 manually.

      When I've seen and reproduced this issue with BC4, it's always been with a TMP file on the left and a file that is checked out from TFS on the right. And through some cool BC4 'magic', it knows that the file is checked out and it labels it as such in the heading (a nice feature BTW).

      I'm not sure if this is significant or not, but I also have Team Foundation Server Power Tools 2013 installed as a Visual Studio extension.

      Hopefully you'll now have the clues you need to repro this issue.

      Thanks!

      Comment

      • Aaron
        Team Scooter
        • Oct 2007
        • 16002

        #4
        Hello,

        When you launch in the problematic case from a TFS diff, if you immediately go to the Tools menu -> Options, and check the Differences section, is the option still enabled? If not and you enable it, does it stick/remember on close and relaunch?

        In my test case, I installed the TFS VSS Provider for 2013, with VS2013 Express, and within the app I go to the Team Explorer tab, Pending Changes section, right click a file I've edited locally (with a previous edit checked in) and I right-click, Compare with Latest Version.
        Aaron P Scooter Software

        Comment

        • davenovak
          Expert
          • May 2008
          • 58

          #5
          That option is definitely persistent between close and relaunch. I even cycled it off and relaunched then cycled it back on and relaunched with no effect for the first compare (though subsequent compares with BC4 running always correctly honor that setting).

          This definitely has something to do with the fact that one of the files is checked out since comparing the same files in a tmp directory always works correctly.

          Comment

          • Aaron
            Team Scooter
            • Oct 2007
            • 16002

            #6
            Interesting. If you follow similar steps as I outline above, and edit the file locally, does it reproduce for you? I set up everything myself, so I currently only have a TFS of 1 user: I check in a file, then Edit it, the compare against the source control (local edits vs. previous revision that is checked in).

            And, I assume you have downloaded the TFS MSSCCI Provider. Is this the version you are using? https://visualstudiogallery.msdn.mic...b-49318c143df8

            And did you add the local directory as a controlled directory in the Tools menu -> Source Control Integration dialog?
            Aaron P Scooter Software

            Comment

            • davenovak
              Expert
              • May 2008
              • 58

              #7
              Pretty much everything you described is exactly what I'm doing:
              1. From Visual Studio, I check the existing file out and make local changes
              2. From Team Explorer, I right-click on the file and select Compare with Workspace Version. If this is the first launch of BC4, it shows the problem I reported.
              3. Alternatively, I can run BComp.exe file1 file2 from a command prompt (passing an exact copy of the server version as file1 and the local, source-controlled version as file2) and also reproduce the problem (if this is first launch of BC4).

              I can confirm your other questions as well:
              1. Yes, I do have the TFS MSSCCI Provider installed (same one as in your link)
              2. Yes, I do have that folder configured as a source-controlled folder in BC4

              One more important note: if I remove my folder from the Source Control Integration list in BC4, I am no longer able to reproduce the problem. Therefore, it has to be something related to the Source Control Integration in BC4.

              Comment

              Working...