Jonas Hultén

Having big merges is simply a fact when working with big code bases. We're working in Unreal Engine and when there's a new version an army of programmers has changed things all over the place. It's bound to be a large merge and changing this is out of our reach. Yes, I could finish the merge.

We had a lot of binaries committed that we built ourselves and then removed. Then an external party readded the binaries. We're merging half a million files so it's easy to end up with 6000 objects to deal with. The client isn't handling large number of files very well. If I end up with 100 000 added and private files, it's really hard to remove them. The client basically breaks down and can't handle selecting that many files in reasonable time. It turned out I wasn't blocked by this because when I tried server-side merge I could manually select the remaining ones after the failure and resolve those.

So the remaining problems with Plastic after filtering my own mistakes are the EOF error message when merging and that (unattended) resolving takes a long time (perhaps an hour in our case).

I found out what the intermediate error was about. There's a file called that in the first private directory and the file is write protected.

I could sort the files on resolution order in the server-side merge and continue the process again and again it seems. I will let this go on during the night. Hopefully it's done by tomorrow. It is INCREDIBLY slow.

I attempted to do a merge from one branch to another in a cloud repository. The merge contained two conflicting files and 6055 change/delete conflicts. I selected all of the change/delete conflicts and resolved by keeping source changes (restoring the deleted files). This took VERY long time and ended with this error message: Received an unexpected EOF or 0 bytes from the transport stream. I couldn't continue the operation on the remaining files because resolved files were invisibly listed amongst unresolved files. I couldn't resolve by selecting all of them (because they have different resolve status) so I thought I'd attempt a server side merge. I switched branch and it left me with private files I could no longer delete. The error message was: Access top the path 'INTERMEDIATE' is denied. The files themselves has nothing called INTERMEDIATE in their paths or names. The whole thing seemed to be in a broken state at that point. I restarted the client and also the computer without luck. Then I decided to attempt a server side merge. That resulted in the same error with the transport stream. So I'm in need for a solution or workaround to this. I can't seem to resolve this on my own.

I'm blocked from committing a change because the file is locked. That makes sense to me, but I also can't put it on a shelve! To me this feels wrong and will hinder me from doing logical things. My use case is: I'm on a branch doing throw-away testing things. I'm not checking anything out because I simply won't be merging anything back from the branch. There's a bug in my branch that was fixed on mainline. I try to cherry-pick, but I have to clean my workspace to do that, so I tried to shelve my changes and wasn't allowed to do that because of locks. So I'm basically forced to take manual copies on the file on disk to keep my changes.

I can't move changed files to another changelist for some reason. The option is grayed out. I'm on 11.0.16.7303 in the old GUI. I can create a new changelist (persistent or not) and it still won't be possible to move changed files to it.

The zooming issue is caused by a difference in the settings file format between the old and new UI. The workaround is to just zoom out manually until the branch explorer looks normal again. It is triggered by zooming in the old UI and switching to the new UI.

The color filtering problem was probably my fault. I hadn't enabled the checkboxes for the filters and pressed 'apply'. So they weren't active for that reason.

I got this problem as well now. Switching to legacy GUI worked for me.

The other views are working as normal so only the branch explorer seems affected. The scrolling area is huge but I looked in the four corners and found nothing. Then I tried zooming and I found a date as large as the screen itself. From that point I managed to zoom out to a normal view again. Somehow the client zoomed in more than it should be possible. I can't zoom in that much by myself. My color filters aren't working now (in the new GUI). I'm not sure if that's related. All checkins are the same standard white color. For example my "owner = 'me'" filter should change the color but doesn't.

The legacy UI shows the view correctly so it seems related to the new GUI.

After three weeks of vacation I came back to an empty branch explorer view. I'm on 11.0.16.7248. I tried filtering from a date a year back without any change. The view is still empty. I'm currently in a branch that has the last changes the 7th of July. I can see the changesets in the changeset view so the cloud repository is connected and appears to be working apart from the empty branch explorer.

When I updated to 11.0.16.7110 it looks like the format filters stopped working (in the new GUI). I have owner filters that change the colors in the branch explorer and now they are ineffective. The filters are there but the colors on the commits is unaffected.