Announcement

Collapse
No announcement yet.

Take Right Then Left Conflict

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Take Right Then Left Conflict

    When merging a file that has a single 1-line conflict, taking one side then the other causes the prev conflict button to light up as if there were another conflict above the current one. See screencast.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  • #2
    Sorry, my screencast shows a multi-line conflict, but it happens with single line conflicts as well.
    BC v4.0.7 build 19761
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

    Comment


    • #3
      Michael,

      This was a design decision. When there are conflicts, editing text does not automatically resolve them. All conflicts need to be manually marked as resolved by clicking on the red conflict ! marker or selecting "Edit > Conflict" from the menu.
      Chris K Scooter Software

      Comment


      • #4
        I think you are mis-understanding me.

        I did not ask for the conflict to be resolved automatically. I know how to click the conflict icon to mark the conflict as resolved. That is not the issue.

        The issue is that I am in the only unresolved conflict section in the merge session. Both conflict arrows (prev & next) are dark because there are no conflicts before or after the conflict that I am currently in. If I choose "Take Right then Left" from the context menu, then I am still within that same conflict section. The Prev and Next conflict arrows should remain dark. The prev button, however, does not stay dark. It indicates that there is another conflict section before the one I'm in. If I click on it, however, it does not take me to a new section. It keeps me in the current section and goes dark. My point is that is should not have become light in the first place.
        BC v4.0.7 build 19761
        ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

        Comment


        • #5
          Michael,

          Actually, after you "Take Right Then Left", the cursor is on the next line below the conflict section. This is why the "previous conflict" button is still enabled.
          Chris K Scooter Software

          Comment


          • #6
            Well, that explains it. Thank you. Could we please change it to keep the selection within the change section? When I take a single side, it leaves me in the change section. I would rather not be moved out of the change section simply because I took both sides. It is not consistent with how the gutter take buttons work.
            BC v4.0.7 build 19761
            ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

            Comment


            • #7
              Thanks for working on this. It is much better now. However...

              The Change Log for build 3.0.11.9510 says:

              - Text Merge
              - "Take Left Then Right"/"Take Right Then Left" now preserves the original caret position.

              This is not necessarily true. Please see this screencast...
              BC v4.0.7 build 19761
              ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

              Comment


              • #8
                I am unable to reproduce this. Please send your settings and sample files to support@scootersoftware.com.
                Erik Scooter Software

                Comment


                • #9
                  The key is that the lines following the diff sections are shorter than the cursor position I clicked in when taking both sides.

                  It would appear that BC3 moves the caret to the next line before the caret is put back on the line that had focus when the user intiated the take. The end result is that the caret is sitting in the column position of the end of the next line instead of in the original column.

                  You should be able to repro this in-house easily enough. Please let me know if you still need sample files.
                  BC v4.0.7 build 19761
                  ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

                  Comment


                  • #10
                    No, I am not able to reproduce this.

                    I tried disabling "Allow positioning beyond end of line" which is the only thing I could think of that might cause this, but it didn't make any difference for me. FYI, the caret moving to the next line and back is expected.
                    Erik Scooter Software

                    Comment


                    • #11
                      And you tested with files in which the "next line" is very short, as in my screencast?

                      It is only two characters long...a SQL Server line comment with nothing in the comment:

                      --ğ
                      BC v4.0.7 build 19761
                      ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

                      Comment


                      • #12
                        Yes, I did. I have finally found a case where I'm able to reproduce this and will have a fix in our next release (3.0.12).
                        Erik Scooter Software

                        Comment


                        • #13
                          Thanks. My testing confirms that this is fixed in release 3.0.12
                          BC v4.0.7 build 19761
                          ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

                          Comment

                          Working...
                          X