[4.8.3] Sync sometimes doesn't update assets in the editor (Subversion)

We’ve been using the integrated Source Control (Subversion) for about two weeks now. So far, we had it happen at least 3 times (that we noticed!) that one user’s submitted changes ended up overwritten by another user despite both of them using source control.

I’ve asked around each time and what each of these cases had in common was that the user overwriting the changes used the in-editor Sync command to update the repository. As far as I can tell, this will always bring the repository up to the latest revision, but does not always refresh the local version. (Nor does it always cause problems.) After closing and then reopening the editor, the changes are displayed correctly.

I’ve currently got two theories as to how this might happen:

  1. it happens if the changed asset is currently opened in the editor, or
  2. it happens if the syncing user has local changes

If the latter, it would be a result of the non-existent conflict handling of the editor’s source control system. If the syncing user has local changes in the asset, the source control doesn’t warn about the conflict. In fact, there’s no indication at all that the asset was changed by anyone (other than it having been locked beforehand) seeing how the conflicted asset is displayed using the local version.

Obviously, working on assets that are currently locked by someone else is suboptimal (because the changes will have to be discarded) but is sometimes unavoidable if I want to test my changes in a different Blueprint. For example, I might have to tweak some values in the Game Mode or attach a new component to an existing character to test my changes under realistic circumstances.

Hey -

I just want to make sure that I understand you correctly. When two people have the same asset checked out and both make changes, the changes of the first person to submit the asset back into source control are lost when the second person submits their changes, correct? If this is not the correct understanding then please elaborate on what exactly is happening when the two people both try to submit/sync the asset.


Close. The asset is never checked out by two people at the same time. The second user checks out the asset after the first user has released the lock (by checking in their own changes).

  1. User A checks out an asset and edits it.
  2. Meanwhile, user B also makes some changes to the file. (I’m not entirely sure that this is a requirement, but it seems like a likely cause.)
  3. User A checks in their changes.
  4. User B syncs their repository. In the editor, the asset doesn’t get refreshed, so B continues working on the asset with their own local changes started on a version preceding A’s commit.
  5. User B checks in the asset, thereby overriding A’s changes.

Locally working on locked assets can always cause trouble if the user isn’t careful. The problem is that, once A has checked in their changes, user B gets no further feedback they’re about to override another user’s changes. In particular, syncing appears to result in the same asset state both if A reverted their change or checked the asset in: in both cases, the lock is released and B is free to check it out.

What muddles that theory is that closing/opening the editor has forced a refresh on all my own attempts to reproduce this. I would have thought that asset conflicts would persist. If they do, a conflicted state might not actually be a requirement for this behavior.

Thanks for your quick reply!

I just tested this again. This time I made absolutely sure I had no local changes (reverted everything in TortoiseSVN) before opening the editor and syncing.

Then I used Diff Against Depot on one of the changed assets. This showed several local changes that were an inversion of the latest changes in the History. Checking in TortoiseSVN confirmed that I didn’t actually have any local changes.

After closing and reopening the editor, the asset’s local version matched the latest revision.

So this bug exists independently from conflicts.

Also, this is probably a duplicate of Perforce Sync not refreshing properties in Content browser and scene - Pipeline & Plugins - Epic Developer Community Forums

Hey -

We were able to reproduce this and have entered a report to investigate this bug (UE-20363).


Hopefully this gets fixed ASAP

From another post Perforce syncing does not update UE4 Content Browser (but the files on hard drive are being updated) - Programming & Scripting - Epic Developer Community Forums

Hello Wheeze,

We’ve had a few other users report
this issue as well and I’ve previously
placed a bug report in for this. You
can find it here: UE-20789.
Unfortunately the only workaround at
the moment is to restart the editor.
Please feel free to vote on the report
so that we know people are interested
in getting it fixed, and hopefully
make it more of a priority. more ▼

answered Aug 30 '16 at 12:23 PM
Matthew Clark gravatar image

Matthew Clark :diamonds::diamonds: STAFF
19.7k ● 405 ● 37 ● 297

Hi, I fixed this by workaround, just use button to submit something even if your checklist is empty.