Using history to better explain branch differences
Release BL647 introduced a great step ahead in the way in which branch (and cset) differences are displayed and explained. Now it is possible to understandwhere each difference comes from:
The case of merged files when diffing branches
I’m going to start with a very simple case to explain you what the new feature is about. I have a branch as follows:
It starts from label 603 and makes a simple change on a couple of files. The change I’m interested on happens on file ClientFileSystem.cs and is:
I just changed a param in the WriteSelector method and removed a few comments.
And this is my branch diff at this point, quite easy to understand since I just changed a couple of files:
Now I’m going to rebase from BL604. A bunch of files where modified between BL603 and 604, ClientFileSystem among them. My branch now looks like this (note I used ‘display only relevant changesets’ option to shrink the diagram):
And now this is the diff of the “filesystem-fix” branch:
Well, what is the great thing about this diff?
First take a look at the top of the diff panel:
The diff is helping you to understand the change because instead of a regular diff, it is grouping the files depending not only on the category (added, changed, deleted, moved) but also on whether they come from the branch being diffed itself, or from the merge.
Note that the “CC” group means files in conflict (CC stands for changed-changed which means it has been modified both on the branch and during the merge).
This is not new, in fact we released this feature long ago as part of BL505. But I wanted to highlight it again because first it receives some improvements, and second, in order to compare it with a diff without the same “treatment”. Look how a regular branch diff would look like:
The advantage of using historical information to “decorate” the diff is clear, isn’t it? Instead of a bunch of “changed files” you now see a much more understandable solution which clearly explains you what comes from the rebase and what was modified on the branch.
Dissecting merged files
We’ll focus now on the first file I modified: ClientFileSystem. Remember it was also modified during the rebase because it was modified between label BL603 and BL604.
Take a deeper look at the lower part of the diff window now because this is where the news are:
Yes, now it is possible to find out where each change is coming from. Using different colors the diff highlights the changes coming from the merge, the ones done on the branch, and will render in RED the ones that were modified *during the merge* as part of a conflict resolution.
Why is this so useful? Well, when you’re reviewing code from another developer and the branch you’re reviewing contains merges, it is normally difficult to figure out what was really modified on the branch and what is just coming from another one (which in turn can be already reviewed, which should make your job easier). This new feature clearly highlights what happened to the code, making code reviews much easier using Plastic.
Better diffs for files added during the merge too
I’ll continue using the same branch but now I’ll do something as follows:
The new “fsproxy” branch adds a new file FsProxy.cs. Then we merge fxproxy into filesystem-fix and make a change to the file. The branch diagram is now as follows:
Now let’s check the diff of branch “filesystem-fix” again:
As you can see instead of seeing “FsProxy.cs” as “added” as a regular diff would do, now it is very clear that the file was added during the merge and the actual modification you did on the file.
Previously (and with any other version control system) you’d just see FsProxy.cs as new and you wouldn’t be able to clearly distinguish what you changed on the file (unless you started to diff each single changeset on the branch).
The new improvements in branch and cset diff let you understand the changes much clearly than before. In order to do that Plastic doesn’t only diffs the trees associated to each changeset, but also calculates the individual history of each file to be able to find out what was merged and when.