x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Office Holiday

Epic Games' offices will be on holiday from June 22nd to July 7th. During this period support will be limited. Our offices will reopen on Monday, July 8th. 

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

Product Version: UE 4.8
Tags:
more ▼

asked Aug 24 '15 at 02:27 PM in Bug Reports

avatar image

erinacea
1.8k 69 28 113

avatar image Doug E ♦♦ STAFF Aug 24 '15 at 04:10 PM

Hey erinacea-

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.

Cheers

Doug Wilson

avatar image erinacea Aug 24 '15 at 05:04 PM

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!

avatar image erinacea Aug 25 '15 at 06:18 AM

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 https://answers.unrealengine.com/questions/59903/perforce-sync-not-refreshing-properties-in-content.html

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hey erinacea-

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

Cheers

Doug Wilson

more ▼

answered Aug 25 '15 at 04:36 PM

avatar image thevfxguy13 Nov 01 '16 at 05:41 AM

Hopefully this gets fixed ASAP

From another post https://answers.unrealengine.com/questions/477322/perforce-syncing-does-not-update-ue4-content-brows.html

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 ▼ Newest

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

Matthew Clark ♦♦ STAFF 19.7k ● 405 ● 37 ● 297

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question