Single branch workflow improvements: announcing Incoming Changes
UPDATE March 6, 2020: We updated the Availability section to highlight that the Incoming Changes feature is enabled by default.UPDATE February 27, 2020: We updated the Limitations section because the ones related to multiple heads and writable Xlinks don't apply anymore.
UPDATE November 21, 2019: We updated the Limitations section because Incoming Changes is also available for macOS.
UPDATE November 8, 2019: We updated the Limitations section because some of them don't apply anymore.
Many teams, especially in the gaming industry, use a single branch. We have greatly improved their workflow so that they don't have to struggle anymore with unneeded merges.
We still recommend task branches but we understand not all our users can't adopt them. Plastic is all about flexibility (that was the story behind its name, after all) and we decided to greatly simplify the single branch workflow.
This is the new Incoming Changes view, a way to preview, download and solve conflicts when you are behind the head of your working branch.
Next, I'm going to guide you through each of the new features and improvements we included as part of the new Incoming Changes.
Notification of new changes in the workspace status bar
It will be now clearer when you are behind the head.
When there are new changesets, but they are not in conflict with your local changes, you'll see a green bar like this:
But, if your changes are in conflict with the new changesets, the bar will turn red, prompting you to take action:
Keeping a linear history
Let's now delve into the core of Incoming Changes. Teams working on single branch want to keep their history linear, instead of seeing tons of merge links and subbranches in their branch. And that's exactly what we changed.
I'll explain it with an example in the figure below. In the next Branch Explorer you have modified a file named FileSystem.cs, but meanwhile, someone added a MOV video and then modified FileSytem.cs.
Before Incoming Changes – regular merge
How does Plastic behave before Incoming Changes? Without Incoming Changes enabled, Plastic takes you to a merge window and merges the head into your working copy. The merge preview is as follows:
The merge preview clearly shows that FileSystem.cs is in conflict, which is fine, and that a new file needs to be downloaded, which was also fine.
Then, you merge and go back to Pending Changes. Here is where things get confusing for many users. Look at the following screenshot:
Many users struggle with this. They shout, "Why on earth am I seeing merge links if I just want to update to head?"
Also, they cry, "Why if I only have my FileSystem.cs modified now I see this .MOV file in my Pending Changes?"
The example picture above is simple because only one file was copied (copy-merge we call it) into the workspace as part of the merge, but very often there are hundreds or even thousands of files, so it is very easy to lose context. You have just one file in conflict, you update to head, and now you have thousands of "changed" files.
While this behavior is perfectly fine for merges between branches, it seems to be a pain when just updating to head.
This is what the Branch Explorer shows when the result of the merge is not checked in:
And, to make things even worse, the image below shows what happens when you checkin. Now, you have what we call a sub-branch, a branch inside a branch. And you just wanted to work on main!
If you are a merge-savvy user, probably you don't have any issues with this, and it is perfectly fine for you. But, even if you are an expert, when working side by side with a team mate on the same branch, you were hit by this sub-branch situation thinking that a linear history would have just been better here.
Solution with Incoming Changes – a linear history
Ok, let's now repeat the same scenario equipped with the new Incoming Changes feature.
You are working on the FileSystem.cs file. Go to Pending Changes, and you see the red bar warning you that FileSystem.cs is in conflict with head.
You click Resolve and enter the new Incoming Changes view, which clearly shows what is in conflict. Yes, Incoming Changes is based on the merge (there's a merge underneath after all) but we greatly simplified it, added colors to highlight the really important things and removed uninteresting actions.
Then, you click on Resolve conflicts, and your workspace is updated to head, merging FileSystem.cs with the latest changes in the head of the branch.
Plastic now also shows progress during the update for the files that are downloaded. This is extremely important when downloading GBs of data, because before that you didn't know if the app was stalled or what:
Now, you go back to Pending Changes and...
Voila! As you expected, only FileSystem.cs is there. The big .MOV file doesn't show up as a change because you were just updating to head, that's all.
One important thing here to note is that when you diff FileSystem.cs now, you'll continue just seeing what you changed, this time against the current head, of course.
And, the Branch Explorer is now linear too:
The expert in the room says: "Hey! This is a Git rebase"
Well, sort of.
There is one thing that is important to highlight. Git can't work centralized, and the situation I described only happens when you are working centralized with different developers working on the same branch concurrently.
In Git (and in Plastic if you are working distributed), you always commit to a local branch that you later push to a central repo. There is no way for two developers to commit to the same branch without one of them pushing first.
Centralized means you can effectively commit to the same branch. Perforce, Plastic, SVN can do that. Git can't.
Centralized means you do not need the extra push.
The extra push is great (Plastic can work distributed too, natively), but many version control users struggle with it. Typically, non-coders.
That being said: yes, Incoming Changes does a "Git-style" rebase with your local changes. Basically, it moves your changes from where they were created to head, merging whatever is in conflict to ensure consistency.
Availability
Since 8.0.16.3975, the Incoming Changes feature is enabled by default. If you download this version or later, you can skip the following
client.conf setting.
If you want to try Incoming Changes you need to:
- Download 8.0.16.3685 or later.
- Upgrade your client and servers. NOTE: you need to upgrade the server too.
- Enter this in your
client.conf:<EnableIncomingChanges>yes</EnableIncomingChanges>
We release it under a feature toggle because we want feedback from early adopters before making it available for all users. It is a big workflow change, so we want to be as careful as possible.
Limitations
As of 8.0.16.3685.
- Incoming Changes is not yet available for Linux.
- Readonly Xlinks are not properly handled. Don't use Incoming Changes if you need to handle changes inside readonly Xlinks because it won't work well. Disable Incoming.
- The filesystem protection changes are not handled by the Incoming Changes. These are just skipped at the moment.
- The Incoming Changes doesn't handle properly the following scenario related to Xlinks:
- I am working at cs:3.
- Another user removes an xlink (x1) at /xlink cs:4 and creates a new xlink (x2) pointing to a different repo at /xlink too and check it in (cs:4).
- The Incoming Changes fails when updating the workspace from cs:3 to cs:4.
Limitations removed in 8.0.16.3975:
- Can't resolve file conflicts when there are multiple heads in the branch.
- The Incoming Changes doesn't handle properly change in the expansion rules of writable Xlinks. After running the incoming changes, you can see checked-out Xlinks that weren't there before.
Limitations removed in 8.0.16.3760:
- Incoming Changes is only available for Windows.
- Incoming Changes is not yet available for macOS.
Limitations removed in 8.0.16.3708:
- The menu to diff files is confusing because it is the same as the merge. It says things like "diff source with ancestor" (which diffs the change you're about to download) and it is not clear in the Incoming Changes context.
- Fails when the changeset loaded in the workspace is deleted. We are working to fix it.
Limitations removed in 8.0.16.3691:
- Not optimized after creating a new workspace. The Incoming Changes notification shows up when you create a new workspace saying there are tons of new changesets. This is because workspaces are created empty and pointing to the changeset zero of the main branch. Incoming Changes works well here, but it is more efficient to just launch a regular update. We'll get this one fixed asap.
- Incoming Changes is not refreshed after undoing local changes, which is not correct. We are working to fix it.
- Incoming Changes is closed when the update/conflict resolution finishes, but it is also closed incorrectly if a file is locked and the update can't happen.
- Plastic still doesn't launch Incoming Changes instead of a regular merge when invoked from the Update in Workspace Explore and there are conflicting changes in the workspace (behaves differently than Pending Changes and the new notification area).
- Plastic doesn't hide the new changes notification bar when switching workspace, which can create issues if you switch and click before it updates the status.
- The workspace status is not correctly updated. You are on cset 100, use Incoming to move to head (cset 200), but the status area still shows cset 100 incorrectly.
0 comentarios: