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’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.
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.
yeah,
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).
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.
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.
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.
