Skip to main content

It seems that the Software Factory doesn't handle deleted objects well in branches that are kept open after merging (tested in SF 2023.1). This is demonstrated with the following scenario:

  1. Create branch DEVELOP (from MAIN)
  2. Add column X in branch DEVELOP
  3. Merge DEVELOP back to MAIN and keep the branch open
  4. Delete column X in branch DEVELOP
  5. Merge DEVELOP back to MAIN

The result in the MAIN with this scenario is that column X still exists in the MAIN after step 5. We assume at step 5 the SF makes a delta from the starting point of the branch with the current state of the MAIN and the current state of the branch and determines that column X was added in the MAIN after creating the branch. However, this is not the result that we want/expect (Column X should not exist in the MAIN after step 5).

When the scenario is changed to:

  1. Create branch DEVELOP (from MAIN)
  2. Add column X in branch DEVELOP
  3. Merge DEVELOP back to MAIN (make the branch inactive)
  4. Create branch DEVELOP_2 from MAIN
  5. Delete column X in branch DEVELOP_2
  6. Merge DEVELOP_2 back to MAIN

The result is that column X doesn't exists in the MAIN after step 6 (as expected).

So based on these scenario's one could say that it is always better to create a new branch after merging over keeping the branch open and continue working with it. However this is not possible when there are existing sub-branches of the DEVELOP branch (for example FEATURE branches). These FEATURE branches would require the original branch of which they origin to keep existing in order to be merged back. This approach was suggested in:

So to cope with this, we executed the following scenario:

  1. Create branch DEVELOP (from MAIN)
  2. Add column X in branch DEVELOP
  3. Merge DEVELOP back to MAIN and keep the branch open
  4. Merge MAIN back to DEVELOP
  5. Delete column X in branch DEVELOP
  6. Merge DEVELOP back to MAIN

The result is that column X doesn't exists in the MAIN after step 6 (as expected). The result is different than the first scenario because the SF updated the origin model version to the point in time of step 4.

 

So our conclusion is that when you leave a branch open to continue after a merge, one should always merge back into it to update the point in time of the origin model version.

This is not something that every developer will probably think of when executing a merge session. Therefor we suggest that the execute merge session task starts a new merge session back into the branch when ‘Deactivate branch’ is not selected. Of course there should be a tooltip explaining why this is happening (or another checkbox could be added to start the merge session so the user still has a choice). If there are no open conflicts in the new merge session it could even execute that merge session directly.

Of course we hope that Thinkwise will be able to come up with an even better solution, because always having to merge back makes the process quite tedious.

@PeterKeeris great that you managed to find a reproduction scenario for issues related to reusing Inactive branches. We have had some headache experiences with this as well, so internally agreed to never continue working in a merged branch. However, we never really got our head around what exactly goes wrong, which is why we never raised a TCP. 

Thinkwise should properly fix this, so hope you raised a TCP issue? 

Hi all, this specific situation has been resolved with Thinkwise Platform version 2023.2:

Release Notes 2023.2 - Delta actions determined correctly when branch is merged multiple times

The situation is indeed as you described it and for 2023.1, it is best to merge the origin back to the branch after merging the branch to the origin, when you plan on keeping the branch intact for further development.

Hi Anne, Great to hear that the problem is resolved in 2023.2. Unfortunately we are hindered with upgrading to that version until we have replaced the Mobile GUI with the Universal GUI. Would it be possible to hotfix this in our 2023.1 SF?

Hi Peter,

The change in 2023.2 tracks merge directions and prompts the user with instructions to update the branch by merging the origin before the user is allowed to merge the branch to the origin again.

This is unfortunately not something that can be hotfixed by replacing a piece of code as this is a complete, embedded process.

If you not deleting the merge sessions after a successful merge, you can make a custom validation that checks to see if a merge from the origin to the branch has been done since the last merge of the branch to the origin. This validation will then light up in DEVELOP if DEVELOP is not ready to be merged to MAIN.

Terms & ConditionsCookie settings