Editor merge is extremely slow on a ~260 GB project; no diff list after resolving conflicts (only “Complete merge”)

Help & Support
1

Summary / Question
We have a large PlayCanvas project (~260 GB). Merging branches/checkpoints is consistently very slow: the “Resolve conflicts” phase takes tens of minutes, and after conflicts are resolved the diff list does not render—the panel stays blank and I can only click “Complete merge”, which then takes another tens of minutes to ~1 hour.
I’d like to understand what causes this (asset count vs. big binaries vs. scene JSON size, etc.) and what we can do to optimize it. Any known issues or recommended best practices?

Environment

  • Editor: [1.77.0]
  • Browser: [Chrome 141.0.7390.123.]
  • OS / Hardware / GPU: [macOS, RAM 16GB, CPU intel core i7 2.8GHz, GPU Intel Iris Plus Graphics 655 1536 MB]
  • Reproducible for teammates on different machines/networks: [Yes]

Project Scale

  • Total project size: ~260 GB
  • Many binary assets (textures/models/audio): [Yes; Thousands of sprites.]

Steps to Reproduce

  1. Create/choose source and target checkpoints for two branches.
  2. Start merge in the Editor.
  3. Wait through “Resolve conflicts” (takes tens of minutes even for tiny or zero changes).
  4. After conflicts are resolved, the diff list panel does not show changes; only “Complete merge” is available.
  5. Clicking “Complete merge” takes another tens of minutes to ~1 hour until the merge finishes.

Observed Behavior

  • “Resolve conflicts” takes tens of minutes.
  • After conflicts are resolved, the diff list does not appear (blank), so I can’t review what will be merged.
  • “Complete merge” then takes additional tens of minutes to about an hour.
  • This occurs even when there are no changes or only one or two script (text) changes.

Expected Behavior

  • Reasonable merge times, especially when the change set is tiny or empty.
  • Diff list should render after conflicts are resolved so we can review before completing.

Diagnostics I’ve Already Tried

  1. Create checkpoint before merge: creating a checkpoint costs ~3–5 minutes, but this is not the main problem.
  2. Zero-change merge: even with no file changes, “Resolve conflicts” still takes tens of minutes, and “Complete merge” also takes tens of minutes.
  3. Only 1–2 script file changes: same behavior—tens of minutes during resolve, then tens of minutes to complete.
  4. Scene-heavy vs. script-only merges: similar timings (still tens of minutes to ~1 hour); I don’t see a clear difference.
  5. Binary-heavy merges: similar timings; again no clear difference.
  6. Disable “Create checkpoint first”: saves the initial 3–5 minutes, but the long times in “Resolve conflicts” and “Complete merge” remain.

Questions for the Team

  • What are the main drivers of merge time in the Editor (total asset count, large binary assets, large scene/template JSON diffs, something else)?
  • Are there known issues where the diff list fails to render after conflicts are resolved? Anything we can collect to help (HAR, console logs, project ID)?
  • Are there recommended best practices to keep merges fast for large projects (e.g., more frequent checkpoints, scene/template organization, splitting large scenes, handling big binaries differently)?
  • Is there any server-side queueing/backoff we should be aware of, or regional factors that could explain the timings?

Thanks in advance for any pointers or troubleshooting steps!

2

Hi Satoshi

  1. The merge time itself is down to comparing all the assets scenes and project settings to calculate diffs. This is a legacy algorithm and we have been working on improving it.

  2. There has been one prior issue where diffs fail to load but that was a frontend issue I believe and not server side. I will need to verify that with you project.

  3. Yes please could you add me to your project username: kpal. When attempting to create/apply merges or viewing diffs please send screenshots of the Chrome Dev Tools to show any errors.

  4. Its unlikely that projects of this size were taken into account when the original version system was created so keeping the scene size and number of assets down to a minimum would be the primary best practise.

  5. There is a queueing system for version control operations but the queue time should me minimal. Regional factors do not affect this. The only aspect that might be an issue is job run time which i will investigate for you.

Kind regards
KPal