Received an unexpected EOF or 0 bytes from the transport stream

[Jonas Hultén]

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.

[Jonas Hultén]

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.

[Jonas Hultén]

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.

[Jonas Hultén]

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).

[calbzam]

18 hours ago, Jonas Hultén said:

The merge contained two conflicting files and 6055 change/delete conflicts.

Why do you have such a number of change delete conflicts? This should be the first thing to clarify. It shouldn't ever happen on a normal basis. We may need to re-evaluate your merge workflows.

 

3 hours ago, Jonas Hultén said:

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).

When a conflict is processed, the merge is recalculated because this conflict resolution may have generated more conflicts that need to be addressed (dependencies between conflicts). And with such a number of directory conflicts, it may take a very long time to finish. 

If I properly understand, this EOF is preventing you to finish the merge (even considering it's slow to process all the merge conflicts)?

Regards,

Carlos.

[Jonas Hultén]

On 2/24/2023 at 11:34 AM, calbzam said:

Why do you have such a number of change delete conflicts? This should be the first thing to clarify. It shouldn't ever happen on a normal basis. We may need to re-evaluate your merge workflows.

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.

 

On 2/24/2023 at 11:34 AM, calbzam said:

When a conflict is processed, the merge is recalculated because this conflict resolution may have generated more conflicts that need to be addressed (dependencies between conflicts). And with such a number of directory conflicts, it may take a very long time to finish. 

If I properly understand, this EOF is preventing you to finish the merge (even considering it's slow to process all the merge conflicts)?

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.

 

[calbzam]

1 hour ago, Jonas Hultén said:

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.

In Plastic, we always encourage the branch per task methodology so you can create and merge short branches. Having big bang merges is not something you should have in your project and we should find a way to readapt your workflow to avoid it from have again in the future.

 

1 hour ago, Jonas Hultén said:

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.

Ok, can you confirm you were able to finish the merge?

[Jonas Hultén]

On 2/27/2023 at 12:20 PM, calbzam said:

In Plastic, we always encourage the branch per task methodology so you can create and merge short branches. Having big bang merges is not something you should have in your project and we should find a way to readapt your workflow to avoid it from have again in the future.

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.

On 2/27/2023 at 12:20 PM, calbzam said:

Ok, can you confirm you were able to finish the merge?

Yes, I could finish the merge.