Source handling: Restore messes up merges

Hey, I’ve encountered a rather problematic issue related to the source handling in Playcanvas a couple of times now, And we have yet to find a good solution to it.

The issue arised both times when we had to revert our master branch a couple of checkpoints due to unexpected issues. However, this also reverted a merge into master from another branch. After this it is not possible to merge this other branch into master again to get the changes made there, since every time the merge result is just “no changes found”.

I made a diagram describing the issue here:

I’m assuming what is happening during the 2nd merge from the Branch into Master is that despite the revert it compares it’s changes to checkpoint M3 in the diagram, and not M1 as would be expected. Thus the merge attempt comes up with “no changes found” and you are basically left with a messy history and no apparent way to get the changes made in the Branch back into Master.

Is there a way to solve this issue, without having to redo every change made in the Branch? I found this thread, which seemed to have a solution to a similar issue, but I couldn’t get it to work.

Also, it would be nice if the engine could be updated soon so we don’t have to deal with this every time we have to revert a couple of checkpoints in Master.

Restore doesn’t delete existing checkpoints/commits.

If you restore M1, it takes the state the project was in M1 and replaces the current project state on top of M3.

The common merge point/ancestor is still B1 → M1 hence why merging branch into master again has ‘no changes’ because no new changes have been made on the branch since B1 (the last merged checkpoint).

It sounds like you want to use hard reset from M3 to M1 which would delete checkpoints M3 and M2.

This is a destructive operation. Make sure you are deleting the right checkpoints!

a hard reset would be preferable, but we’re not allowed to do so since it will destroy the history (since the Branch was merged in in checkpoint M2 basically).

Can you show in the diagram where you’ve merged M2 please?

From what you have shown currently, I can’t see why you can’t hard reset master to M1

A workaround may be to:

  • Hard reset to M2 (undoing the merge of B1 to master)
  • Restore M1 (effectively undoing the changes of M2)
  • Merge B1 to master

Unfortunately that don’t work, we just get the error message:

ofc. this might be because we have done other things since in an attempt to solve this issue… I see a couple of our new fix branches are interfering. However, its my impression we would not be able to hard reset anyways since M3 is effectively dependent on the other “Branch”, so hard resetting from this checkpoint would break the history of “Branch”.

It’s a bit difficult to tell without seeing the actual graph myself but with the diagram above, you should be able to hard reset to M2 as you’ve merged branch to master.

M3 is a checkpoint created by merging B1 to master. Deleting M3 wouldn’t break the branch because it doesn’t affect any dependency in branch

You can’t delete checkpoints if they’ve been used to branch from or if the branch has later been merged into another branch. You would have to ‘unwind’ the graph be hard reseting to delete the merged checkpoints.

I can take a quick look at the version control graph if you give ‘yaustar’ read access and you detail the checkpoint ids that are relevant to the issue

We added u to our project now (Stack’n Load). There’s a bit of branching and stuff thats been done since the issue arrised earlier today, so unwinding the timeline would be a bit of work, but if it is the only solution I guess we just have to do that.

However, I speak for my whole team when I say that we would very much appreciate if these sorta issues were made easier to resolve in the future. For instance a “force reset” that also resets which checkpoint is compared to in future merges, or something similar. In Git at least this is fairly simple to resolve.

The reason we didn’t have a force reset option is because we were concerned that users will delete more than they intended including whole branches.

The original purpose for hard reset is to undo merges instead of doing the nasty workaround that you linked to before.

Saying that, the version control system is under review with a number of internal discussions happening so a lot of this can change in the future.

I will DM you about the project so it’s easier to share more.

ok, thx :slight_smile:
Some sort of easier fix would be rly nice at least

Hey, thought I’d just sumarise what happened here and the solution in case someone else stumbles upon this:

So our problem was as described in the diagram above. We used a restore to backtrack our project removing unwanted changes, but in the process we messed up the history of our project. We made it even more messy by making new branches in an attempt to do a workaround. However this blocked the hard reset function. What actually had avoided this whole problem would be if we had used a Hard Reset instead of a Restore to begin with, thus deleting the history aswell as the merged changes in Master. Afterwards we could have merged in the changes from the other branch again as normal.

Eventually this is what we did, but we had to unravel the whole timeline untill this point (deleting all the new branches made after this mess up). Thankfully Yaustar helped us do all that so it wasn’t too much work. :slight_smile:

However I guess the takeaway from this is: be careful in situations like this, and make sure to use Hard Reset and Restore correctly, at least the way the current source handling works.

1 Like