Skip to content

Conversation

Darcy3000s
Copy link
Contributor

Currently if you run a revert on a deleted file through the source control submit window, you don't actually get the file back because of this piece of code:
// If already queued for deletion, don't try to delete again if (State->IsSourceControlled() && !State->IsDeleted()) { OutMissingFiles.Add(State->GetFilename()); }

But the only place this function is used, is to revert files, so the revert action does nothing - with this change, the revert action will bring the file back to its state at HEAD - I had a bit of a look at the history of this, and it's quite unclear why it was needed, it was added quite a while back, I'd guess the engine used to handle deleting or reverting differently

In addition to this, the behavior of reverting an added file was just to unmark it for add - which is understandable that some folks would want that, but that's not the behavior we want at our studio, so I've made Revert on an added file also remove the file on disk IF you have USourceControlPreferences::ShouldDeleteNewFilesOnRevert() enabled
This is a property that already exists in the engine, and is used by the perforce integration to allow you to switch between the 2 behaviors listed here

There's also a general clean up, the code was a bit difficult to reason about, so I've refactored GetMissingVsExistingFiles into GroupFileCommandsForRevert which gives you lists of files sorted into buckets that we run different commands on so it's hopefully a bit simpler to follow

@mastercoms
Copy link
Member

Hi, thank you for the change. I will look into this soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants