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.

Only the Plastic GUI. I'll gather logs and send an email to support then I guess.

Both user A and B in my cases claim to have only one workspace. User A is a new hire so I don't think a removed workspace can be the cause in that case. I have turned off locking, but we can turn it on again to see if a new problem arises. However, the likelyhood of us finding a reproduction case seems low. We may run into it again, but would it help if we simply had a new case happening? Is there enough logging or metadata to determine the cause just by having it happen or do we need to know how to reproduce it?

We have also been hit by this problem. We are using Unreal Engine and the Plastic plugin and we have added exclusive checkout for .uasset and .umap files. We started with a clean workspace and attempted to move a directory in the editor and it resulted in a bunch of changed, moved, added and deleted files in the Plastic client (11.0.16.6787). When we attemped to check this in, we get an error saying "These items are exclusively checked out by: /Path/To/File.umap (wk:Something owner:my@email)". So it says that user A can't check in because user A have it checked out. Right-clicking on the moved file in pending changes shows that we can do a checkout so it appears to be confused about the state of this file. Another instance of this is that a user B has a clean workspace, makes changes to a specific file and when attempting to check in, the file appears locked by user B. User A can't check in this file either, which would make sense if the file appeared to be checked out in user B's plastic client. We turned off exclusive checkout for these file types but the problem seemed to persist until we removed all locks by force using the command line client.

Windows Defender is complaining again on PlasticSCM-10.0.16.5397-windows-cloud-installer.exe.

The one who had checkin problems recently runs 9.0.16.4361. It must be quite old since I'm on 10.0.16.5338. I don't know if people are using the incoming changes view. I would guess so.

It's taking long because we're working from home due to the pandemic and some of us have poor connections. We're actually not using file locks right now but want to start doing it because we have problems with lots of binary files modified all over the place. I haven't considered distibuted workflow. I can take a look at it to see if it can be used. It doesn't work with locked file types. I haven't tried Gluon. Do you mean that partial workspaces will solve this or that Gluon solves the issue by having a better workflow?

Some of us can generate large amounts of data changes in a day. When the changes should be checked in it takes so long to upload them that someone else is likely to have made a checkin and the upload is dropped. This results in a manual merge step, even if no conflict exists, and then the whole thing repeats since the data has to be uploaded again. This isn't working well. I see a couple of potential solutions from the client's perspective. Upload will complete regardless of other checkins but it will stay in a temporary head until merged with the checkin branch. Checkin will succeed if there's no manual merging needed. This only helps a bit but is perhaps easier to solve. A workaround (that we wouldn't prefer) could be to submit in a branch since that will always succeed and merge. However, then we get the problem that we can't lock files across branches so we will get merge problems with our binary files instead. I'm not sure how to attack this problem with Plastic now. Is there something existing today that will solve this situation or will there be something in upcoming releases that will solve it?

Everytime I update Plastic with a new version I am required to read an 11 page license agreement and accept it. It should be enough to show it only in case it has been changed.