Workspace-less merges: merge-to with conflict resolution

Workspace-less merges: merge-to with conflict resolution

Wednesday, March 28, 2018 Pablo Santos 0 Comments

If you have been using Plastic for a while, you probably know what "merge-to" is and when it is useful. Well, we just made it better; it now supports full conflict resolution! With GUI support for Linux, OS X and Windows available.

Super quick intro to merge-to

Regular merges happen like this: you switch your workspace to the destination (where you want the merge to go) and then you merge from source (what you want to merge from).

Internally we tend to call it "merge-from".

Well then, what is merge-to?

Exactly the opposite: you select a branch and you say where you want to merge it to.

Regular merges require a workspace; merge-to doesn't. The merge happens on the server side completely. But, until now, when a merge-to found a conflict it stopped. Merge-to only worked if the merge was clean, no conflict resolution was required, not even automatically solved conflicts. I mean, if a file was modified concurrently, even if it didn't require manual intervention, then merge-to failed.

We've changed that.

Now, you can simply merge-to any branch with full conflict resolution.

Ok, I get it, but what's the big deal?

Yeah, I hear you saying: "ok, I get it, but what's the big deal? Why didn't merge-to always work like this?"

There is a product vision thing involved here.

Merge-to means you are not using a workspace, so... well, you merge something, but you don't really need to have the result in your workspace at all. It used to scare us.

Why?

This is the regular cycle for a merge:

1. Switch your workspace to the destination branch.
2. Merge from the source branch.
3. Everything merged is now in "checked-out" status in your workspace.
4. You build your code and fix anything that was broken during the merge.
5. You run some tests.
6. If the build and the tests pass, you checkin your changes and you checkin the merge.

What if the merge happens on the server side? Well, there is no "build and test".

Yes, it scared us.

We thought it wouldn't be a good thing to have. It could be dangerous; it could promote "misleading practices".

So why did we implement merge-to now? Easy - users asked for it. "Hey, it would be good to merge directly to main without having to switch to it, only for branches without conflicts, you know". And we did it.

What changed then? What made you change your mind?

Automation.

I think I'm linking to this blogpost in everything I write, but it is really worth it. We changed our way of working about one year ago. We wrote a series of blogposts starting with How we do trunk-based development with Plastic SCM.

We basically automated the last mile. And we loved it! Many customers were doing the same with Plastic at the same time.

The automation wasn't about "checking in directly to main" (like primitive continuous integration circa 2005). Rather, it was about automating the task-branch merge step, so no "human integrator" was needed anymore.

Now you automate branch merges, but what does merge-to have to do with that?

Literally everything. We weren't happy with a world of "you merge and the result of the merge is not tested". But, now we live in a world of "you merge, and the CI process will test every single branch" before it hits main.

In fact, in our recommended approach every task-branch is merged, tested while the code is checked-out, then checked in ONLY if build and tests pass.

What is merge-to with conflict resolution good for, then?

Consider the scenario shown in the image below: you need your task branch to be updated with the latest changes from main because it doesn't merge cleanly (and the CI requires merges not to have manual conflicts. It is a bot, after all). You are on a different task already. What's the regular workflow?

1. Switch to the old branch.
2. Merge from main.
3. Checkin.

Sometimes it is not worth it because you know (you diffed the changes) that the merge is trivial, and you won't even build your code, you just want to solve a simple conflict, that's all. And, it can happen often in certain files like project files, localization, etc. (just to mention a few).

Well, now with merge-to, the process will be much, much quicker: merge-to, solve conflicts, and you're done. No switching workspaces to a different branch or anything.

What merge-to with conflict resolution looks like

You simply launch merge-to and you proceed as you would do with a regular merge.

Then, when you are done, you are prompted to "checkin the merge". Of course, your workspace's Pending changes view is not affected because nothing is happening.

How to test it today

Merge-to with conflict resolution was released in 7.0.16.2077 in feature preview. It means it is fully functional, but not enabled by default.

To enable merge-to, you need to add the following to your client.conf:

<ServerSideMergeEnabled>yes</ServerSideMergeEnabled>

This is expected to change in future releases where this setting will be set to YES by default, and it won't need to be defined.

But, it is preview at this point, so we prefer not to enable it by default.

The tip of the iceberg

Merge-to with conflict resolution (a.k.a. "server-side merges" as we called it internally, or even "workspace-less merges") is just a step forward in a longer path we expect to walk during 2018.

We strongly believe that task-branches are the way to go. And, we also believe that full automation of the task cycle is key to achieving a real uninterrupted flow of finished tasks, which are essential for DevOps, and agile, and even for doing data-driven marketing these days.

Version control can play a central role in that. It can: monitor branches; decide when one is ready to be merged (checking for additional info in the issue tracker); ask the CI to build and test; merge it if everything goes fine; then notify by email, Slack, or whatever your team uses. Part of this responsibility used to be on the CI side of things, and that's what we are also improving. But, our goal is to move beyond that and make it super easy to implement a full automated cycle out-of-the-box.

Right now, many customers (and ourselves internally) are using Plastic with fully automated workflows. But, it required some scripting here and there, gluing together different pieces. Nothing super hard, by the way, but this degree of automation normally happened only on bigger teams that can invest some time in it.

If we really want to help many more teams, we need to streamline the process.

If we want the Plastic server to take care of merging branches by itself, automating as much as possible with our semantic tech, we need it to do workspace-less merges. And, that's the underlying key reason for this new feature.

Note: I'm talking about DevOps, CI and all that. No, we are not moving outside the version control space. We are a version control company. We do the best version control in the market (sigh!), and that's what we will continue doing. All these points I explained only makes it better. We are not stepping outside building stuff around Git or anything. We still do hard core version control, and we'll continue doing that :)

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.