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!
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!
Comment