Bug with BC3 and SVN Merge

[mschier]

Dear Support Team,

in our company we use BC3 (3.3.7) as Merge Tool for TortoiseSVN and C++ code.

In case TortoiseSVN reports a merge problem, entering BC3, quite often the conflicts are "solved".
Generally, this works fine. However, we now found a real problem with merging in case a comment was changed both in trunk and in a branch.

When we use the default setting in the Session Settings that comments are unimportant, then a wrong "merge" may happen as shown in the attached PDF.

Actually, I consider this merge behavior in BC as a bug. Even if a comment is not important, I don't understand why when two persons change a comment, BC suggests none of the two newer versions but keeps the old one. Also, as shown in the constructed example, the final result is not a comment any longer and thus should not be considered unimportant.

We had such problems in real code, and sometimes it also merged old and new comments so that the comment text itself was inconsistent and possibly wrong!

Thanks!

[Aaron]

Hello,

In the example case in your screenshot, the issue is that the left side is entirely unimportant, and the right side is also entirely unimportant (deletion of only unimportant text). In a case where the change is equally (un)important on both sides like this, we represent this as a Conflict, and mark the text in the output as Red, along with the Conflict Marker to designate that user interaction is required. The text in the output defaults to showing the center pane, but only because we do not know which side to take and require user interaction to review.

The Next Conflict button can also be used to automatically take you to the next conflict, and you can manually clear the conflict flag in the gutter after you've resolved the conflict.

The extra //cant believe comment is actually a bit of a red herring, as the entire left file text section is still within a /*comment*/ section, so all of the change is still unimportant, not just the addition of that //comment.

If this were an automerge scenario, BC3 should generate any conflict with CVS markers (taking both sides) which would cause the code to not compile.

If comments were Unimportant, and one side had an important change, then that side gains priority over an unimportant change.

Does this help explain the logic that the Text Merge session is currently using? Please let us know if you have any questions.

[mschier]

Hello,

In the example case in your screenshot, the issue is that the left side is entirely unimportant, and the right side is also entirely unimportant (deletion of only unimportant text). In a case where the change is equally (un)important on both sides like this, we represent this as a Conflict, and mark the text in the output as Red, along with the Conflict Marker to designate that user interaction is required. The text in the output defaults to showing the center pane, but only because we do not know which side to take and require user interaction to review.

Thats ok, but only if you don´t set the options unimportant comments and ignore unimportant differences.
And this settings are default after the installation! like on screen2

The Next Conflict button can also be used to automatically take you to the next conflict, and you can manually clear the conflict flag in the gutter after you've resolved the conflict.

Also ok.

The extra //cant believe comment is actually a bit of a red herring, as the entire left file text section is still within a /*comment*/ section, so all of the change is still unimportant, not just the addition of that //comment.

should only to clarify…

If this were an automerge scenario, BC3 should generate any conflict with CVS markers (taking both sides) which would cause the code to not compile.

If comments were Unimportant, and one side had an important change, then that side gains priority over an unimportant change.

Does this help explain the logic that the Text Merge session is currently using? Please let us know if you have any questions.

The output suggestion have to take left, middle or right solution but not this:

{

delete (1);

}

[Aaron]

Hello,

Something to clarify is that BC3 places:

{

delete (1);

}

into the output pane, but marks this as a Conflict that should be resolved by the user before it is saved. An unresolved conflict is not currently a suggested output. The output should not be saved until all conflicts are resolved manually. The output pane defaults to the Ancestor side per line in the case of a conflict where a suggested line cannot be picked. Since the \* lines can be resolved (they are not a conflict, but a deleted on right Difference), the right side is picked. It is then included as part of the conflict section since it is difference within the context of a Conflict (the "delete (1);" line).

If BC3 were able to detect syntax groupings of lines, we might be able to improve this automatically, but we currently only support line by line.

[mschier]

When will you detect syntax groupings of lines?

[Aaron]

Detecting and parsing syntax is a large project and not something we will likely be able to implement soon. Adding this will help resolve more conflicts automatically, but the current version does not mis-detect this case; it is marking it as a conflict and asking for user interaction to help resolve it.

[mschier]

Detecting and parsing syntax is a large project and not something we will likely be able to implement soon. Adding this will help resolve more conflicts automatically, but the current version does not mis-detect this case; it is marking it as a conflict and asking for user interaction to help resolve it.

Ok, I understand that.

But could you change than the default settings?
If you have the default settings after the installation, session settings -> comments are unimportant and the user choose "ignore unimportant differences" then a wrong "merge" may happen and the User don´t get any informations/warnings! (screen2)

[Aaron]

Thanks for the feedback. The Ignore Unimportant toggle defaults to off, but once it is toggled on once it is sticky and would be remembered for any future sessions. It's something we can look into, but I would recommend toggling off Ignore Unimportant Differences for now to see if there are any conflicts before saving a merge output.

[mschier]

Thanks for the feedback. The Ignore Unimportant toggle defaults to off, but once it is toggled on once it is sticky and would be remembered for any future sessions. It's something we can look into, but I would recommend toggling off Ignore Unimportant Differences for now to see if there are any conflicts before saving a merge output.

If somebody have toggled on Ignore Unimportant Differences, could you implement a message by saving that reminds him to toggled off Ignore Unimportant Differences?

[Aaron]

That's something we can look into. I'll add these notes to our entry on the subject.

[mschier]

Thanks!

I look forward to hearing from you soon.

[mschier]

Unfortunately, I had to find the bug in the Beta 4.0 still exists.

Could you look into this?

[Aaron]

Hello,

This is still an open wishlist entry. We have limited resources we are able to direct with each release, and this is not something we've been able to review or assign yet.

[mschier]

one year later

Could you send me the state to this issue?

[Aaron]

We have been pretty busy with implementing 64bit support and a few other big features. We haven't swung around to Text Merge enhancements yet, but it's still on our wishlist. I would still recommend disabling Ignore Unimportant, or alter the session settings to consider more text as Important, in order to include it as part of the merge.