How does one disallow edits when the asset is not checked-out

We are using Subversion for revision control (ver 4.10.0), and it largely works. We’ve run into a big workflow problem, however.

You can go to any asset (a blueprint, for example) and make changes to it in the editor, even if the asset is not “checked out”/locked by the user. When the blueprint is saved, the editor asks if it should check out/lock the asset. Unfortunately, it may be too late. Someone else might have it locked already, or it may have been committed by someone else in the meantime.

That’s pretty bad, but there doesn’t seem to be any way to get out of this situation. Revert isn’t an option (probably because the file itself is unchanged). I can’t find any way to discard the edits that the editor has. Undoing back to the beginning doesn’t clear the dirty bit on the asset. Doing a Sync with revision control pops up a dialog saying that it can’t unload the assets until they are saved… but I don’t want to save them. The only solution I’ve found is to exit the editor and when it prompts to save these assets, select Don’t Save. (This option is available anywhere else.)

I feel like I’ve missed something somewhere because it seems like a common situation and I haven’t found any other complaints regarding it. It seems wrong to allow edits to assets if they aren’t locked.

We have “Prompt for checkout on Asset Modification” turned on and have tried “Automatically checkout on Asset Modification” both on and off and the same problem exists. We’ve tried svn:needs-lock on assets (which makes them -only when they are Synced) which also seems to have no effect on this behavior.

Any ideas?


If you have “Automatically checkout on Asset Modification” enabled and it is not checking assets out, that sounds like a major regression - is that flag having no effect at all, as I think you describe?

It appears to have no effect until you save. When you save, it then does the lock automatically. But it does not lock the asset when the edit is made.

Thanks - I’m getting our internal QA to verify that this is happening internally.

Hey ColdIronPoz-

I was able to reproduce this on our end and have entered a bug report (UE-23704) for further investigation.