Greatly improved branch (and changeset) diff window to better explain merges.
This feature is an evolution of the original "item-merge-tracking" effort and greatly improves the way in which branches (and csets) receiving merges are diffed.
This feature is one of the most relevant improvements in branch/cset diffing the Plastic SCM team have developed.
When diffing a branch (or cset) that receives one or more merges, it is often hard to figure out what was really modified on the branch and what comes from the merge. It complicates reviewing code, specially when big rebases (merge from parent branch) happens.
Suppose the following scenario:
* You start branch "task1010" from label "build-117" on main.
* You modify a number of files and work on the branch for a couple of days.
* In the meantime "build-118" was created, including changes in more than 250 files.
* Prior to integrate your branch to main you're asked to rebase it to "build-118", so you merge down from label "build-118".
* Now your branch doesn't only contain the changes you made, it also contains all the changes (more than 250 files) coming from the merge.
If another developer (or yourself) diffs the branch "task1010" now, he will have hard time figuring out what was modified in the branch and what was merged. The branch is not clean anymore.
This is precisely what this new feature solves: it is able to split the diffs in groups, so it is easy to understand:
* which files just come from the merge and were untouched on the branch,
* which ones were modified on the branch,
* and more importantly, which ones were modified both in the branch and also in the merged branch, they were merges, and they're grouped under a category called "changed/changed" (or CC for short).
This third group of files changed/changed is the one greatly improved by this feature: when a file was both modified on your branch and also changed in the branch you're merging, it is grouped under CC, but then it was not easy to know which lines were actually modified on the branch, which ones were in conflict during the merge, and which ones were just modified on the source branch of the merge.
Now the branch (and cset) diff is able to render differently the lines that were modified on the branch, during the merge (result of a manual conflict resolution) and from the source branch being merged (automatic conflict resolution), making much simpler to review code of branches (and csets) with one or many merges.