Take Right Then Left Conflict

[Michael Bulgrien]

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.

[Michael Bulgrien]

Sorry, my screencast shows a multi-line conflict, but it happens with single line conflicts as well.

[Chris]

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.

[Michael Bulgrien]

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.

[Chris]

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.

[Michael Bulgrien]

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.

[Michael Bulgrien]

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

[Erik]

I am unable to reproduce this. Please send your settings and sample files to [email protected].

[Michael Bulgrien]

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.

[Erik]

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.

[Michael Bulgrien]

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:

--»

[Erik]

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

[Michael Bulgrien]

Thanks. My testing confirms that this is fixed in release 3.0.12