Rebase your branch in the Software Factory

When working with the Software Factory, often times you create a Feature branch to process your changes in, verify the result, and thereafter merge it into the Origin branch. Robert-Jan made an excellent blog about how the Manage branches with Thinkwise which I recommend reading.

Developing new features can lead to branches being open for a long time. It may be that the feature is postponed, or just very big. A variety of reasons can lead to a branch being open for multiple months on end. Once the time has come for the Branch to be merged with the Origin, the merge session wil perform a difference analysis and show you all the differences between when the branch was created and now. That impact may be significantly large.

With such big impact, it can be difficult to determine the merge session will result in the exact model you desire. You already have the option to first merge the Origin into the Branch to have all the ongoing developments added to your branch. Once done, the branch has all the latest developments of the Origin, and all your additions of the Branch.

As of writing, this merge essentially means that you perform all the Origin actions very fast in your Branch. If right after you that would perform a merge from Branch to Origin, the difference analysis part would still look at all changes between the Branch's creation and now. That impact is now even larger than before. Luckily, all conflicts that result in both the Origin and the Branch having the same object with the same values are automatically resolved. So you do not have to resolve it manually.

But here's the thing

Currently, the Origin model version, the moment in time where the branch either was created or the last reciprocal merge was performed, is not updated when merging from Origin to Branch. This means that all differences from branch creation or reciprocal merge until the moment of merging are examined. The more actions, the more impact.

One unintended side-effect that I have seen through your tickets is that object can "reappear” so to speak.

Imagine two branches Origin and Branch. You personally work in Branch and your colleages have been merging their innovations to Origin. You are getting ready to finish your work, but you do want to test your additions with the additions of your colleagues, so you perform a Origin → Branch merge, updating your branch.

Your branch now contains all the added tables, columns, prefilters, functionality and so on.

If another merge takes place changing the Origin which, for example, removes tables that have been added previously to your Branch, your upcoming merge session from Branch to Origin will re-introduce those removed tables again.

Why is that?

The origin model version is used to determine the start of the branch, and therefore the state of the model at that point is used to see which objects where added, updated, and deleted.

For simplicity, I’ll use ABC to resemble objects in the model.

• The Blue boxes are model states where objects are either added or removed
• The Green line resembles the Delta - the difference analysis considers all actions done between the origin model version and the current point-in-time
• The stripped blue arrows are merge sessions

Now you can see, it's like you have created object B in your branch. Object B is going to be added in the Origin as the difference analysis only sees the differences.

How to resolve this?

We will be updating the origin model version once you merge the Origin to your Branch, essentially Rebasing the Branch.

Now, the following will happen when merging from Origin to Branch:

Now the difference analysis notices that object B has been removed in the Origin, so the addition will not be performed. Object B will not be present in the Origin after your merge session. Awesome!

However… We need your input

We determined we will need to say goodbye to a feature that you may use. The ability to Archive branch manually at a later point in time. This merge strategy will no longer be available when you merge your non-protected branch to the origin.

Similar to described before, actions can be missed completely due to the difference analysis using the origin model version to determine the creation or last update moment. Even an later update merge session from the origin to the branch will not help.

Let's use continue the example above:

First merge:

Second merge:

This time after the previous merge from Branch → Origin, the object A was removed in the branch. We will now perform another Branch → Origin merge.

The delete action of object A is not seen as a change, and will therefore have no effect in the merge session.

And this is just with one object, this can happens to every other object you modify or remove in your branch.

This is a serious problem, and the way to resolve this is by requiring the branch to be either archived, or be reciprocally merged. 

Concluding

I'm looking forward hearing from you all! We want to give you the best experience when merging and sometimes have to make tough choices.  In the future, we want to make Merging similar to Pull requests, allowing you to review and approved changes in the merge session itself.