Skip to main content

Consider the following scenario (from Manage branches with Thinkwise | Thinkwise Community)

In this scenario the Develop branch is merged to the Feature 2 branch. This works fine up to the point that Feature 2 is merged back to Develop. The SF (2024.3) will see all changes made to Develop between the creation of Feature 2 and the merge from Develop to Feature 2 as changes that are also made in Feature 2. This results in a lot of conflicts because everything that was added/changed in Develop will be seen as also added/changed in Feature 2 in the merge proces. 

Conflicts are at least a trigger for a developer to look at it and make a choice, but what makes it  worse is when you have created an object in Feature 1, and after the merge from Develop to Feature 2, the object is changed (renamed or deleted). The merge of feature 2 to Develop will not result in a conflict for this object, but it will add the object again with the old name.

 

Could we be doing something wrong when following this scenario? Or is this a bug?

I noticed that the ‘Origin model version’ of Feature 2 is the date when the branch was created, while I would have expected that this would get updated to a new model version when Develop was merged to Feature 2. 

 

 

 

Edit: In 2025.2, merging the Origin branch into the Feature branch will rebase the branch. More on that here: 2025.2 | Thinkwise Documentation

-----------------

Hi Peter,

This is indeed the result of merging all changes from the Origin into the Branch. We are aware of this, and I have experienced it first-hand a couple times now. Updating your Branch with changes from the Origin is not a bad thing to do but does brings in the possibility of many conflicts.

I noticed that the ‘Origin model version’ of Feature 2 is the date when the branch was created, while I would have expected that this would get updated to a new model version when Develop was merged to Feature 2. 

It did used to work like that actually. However, the origin model version is used as baseline for the difference analysis part of a merge session. Based on that point-in-time, all modifications of the involved branches are taken into account. 

If the origin model version would be moved, objects that were added in your branch prior to the merge session from the Origin into your Branch will not be seen as changes anymore, and then it also results in them not being merged into the Origin at a later stage.

By definition, the Origin model version indicates the point-in-time that the content of the Branch is exactly the same as the content of its Origin.

At this stage, the alternative is to create a fresh new branch from the Origin and then merging your existing feature branch into the new feature branch; an Arbitrary merge. This will apply all modifications of your earlier feature branch on a fresh copy. I haven't tried this myself yet though but this should be the solution.

Hi Mark,

Thanks for your response. 

At this stage, the alternative is to create a fresh new branch from the Origin and then merging your existing feature branch into the new feature branch; an Arbitrary merge. This will apply all modifications of your earlier feature branch on a fresh copy. I haven't tried this myself yet though but this should be the solution.

I will try this next time when we want to update a feature branch. If this works as intended, wouldn't it be better to make this the actual behaviour of the SF when merging back from an origin branch to a feature branch?

If this works as intended, wouldn't it be better to make this the actual behaviour of the SF when merging back from an origin branch to a feature branch?

I would prefer that as well. 😄

Although it would cost more time in the beginning, it will indeed save time at the end when ready to merge from branch to origin. 

Terms & ConditionsCookie settings