How to solve conflicts with blueprints in version control?

Development Programming & Scripting Blueprint
, , , , ,
1

We have a project that has been added to Perforce version control system.

Let’s say we have a blueprint BP at version V1, and the following situation:

  1. Two developers D1 and D2 synchronize BP at version V1
  2. The developer D1 checks-out, changes and checks-in BP to version V2
  3. The developer D2 opens BP still in version V1, and changes it w/o doing the checkout before

Now D2 has a conflict with BP. He’s not able to save the BP, as he needs to make a checkout before, which is forbidden as he’s modifying an obsolete version of BP (V1 instead of V2).
The only way for him to make a checkout is to be able to reproduce all the changes done in V2… which can be very tedious, especially with moved nodes, etc…

This situation can come very often! How can we handle it?

Shouldn’t we have the following behavior in the editor?

  1. Forbid ANY modification of blueprint if the current version is not the latest one (block all), and propose to update the blueprint
  2. When listing the differences between the current revision and the one in the depot, allow to discard a local change, and apply the one of the depot
  3. Give the possibility to completely revert all changes done on the blueprint, and come back to the situation of V1 before updating the blueprint to V2 (revert and sync)
2

It would be great to have a “Strict Check-Out” mode in the options in order to forbid any modification on an item that is still checked-in, and directly show a popup message requesting to make a check-out if you try to change anything in such an element.

3

It seems the UMG blueprints are not even asking for a check-out once you have modified something without doing the check-out before, it’s directly set in conflict…