Just to make sure we're aligned: you need something similar to what we already have, but triggered before the file action happens, right?

// Invoked when a new file is created by Studio
Delegate<void (const Uri& uri)> FileCreated;

// Invoked when an existing file is modified by Studio
Delegate<void (const Uri& uri)> FileWritten;

// Invoked when a file is moved or renamed by Studio
Delegate<void (const Uri& src, const Uri& dst)> FileMoved;

I'm still working through the specific implementation details, so the shape of what's needed is in the process of being discovered.

I noticed that opening the file while it's read-only offers limited option to edit it. We would probably also need to intercept the file open (not ideal, creates file checkouts on files we might not edit) or change the behaviour to allow you to start editing the contents of a read-only file without setting it to writeable (preferred).

Hopefully more specific/complete details next week as I continue working through this.

I noticed that opening the file while it's read-only offers limited option to edit it

We will review this. As far as I understand the only different should be at saving time.

Notes from the P4 integration:

• No event is currently raised for when a file is deleted. We would like one to be able to update P4 with the appropriate change.
• Opening a file while it is read-only on disk causes parts of the UI to disallow changes (current workaround is to raise an event when opening a file to switch it to writeable)
• If the read-only open problem is resolved, we would still need an event before the file is written out to check it out at that point (currently FileWritten is raised after the file is successfully updated)
• It would be helpful to control how a file rename is performed on disk. Current workaround is to trigger a "P4 reconcile" with the old path and the new path, but this is not ideal because P4 may not recognize that the new file is a move of the old file depending on how much its contents have been changed. Preference would be to perform a "P4 move" ourselves, but this requires that the original file still be in the expected location and the new location to be clear of any conflicting files. A hypothetical workaround for now would be to reverse the rename when we receive the event and then get P4 to redo the move.

• We will fix the issue with read-only files.
• We will implement the delete notification (I'm not sure why this hasn't been implemented already).
• We will implement both before and after notifications.

There is already a notification for move operations. If we also trigger this notification before the operation takes place, would that resolve your issues?

It looks like if the event was raised out of Project::MoveProjectItem() and we performed the move before it got to FileExt::Move some important logic wouldn't execute.
We would either need a way to respond to the event to say "thanks, we took care of the move for you" or the logic would need to be tolerant to the possibility that the move already happened.

Yes, I see what you mean now.

I'll first investigate what APIs Unity and similar platforms expose to address this specific problem.

So, it seems that in Unity (https://docs.unity3d.com/6000.6/Documentation/ScriptReference/VersionControl.Provider.html), the client is responsible for performing move operations.

The same applies to delete operations, which must also be executed by the client.

I think we need a different approach here: expose functionality for moving, deleting, and creating files, and provide a default implementation in Studio that operates directly on the filesystem.

I noticed that opening the file while it's read-only offers limited option to edit it

This should now be fixed with r18290. User is able to edit a file with read-only attribute, and when they try to save their changes, they'll get a popup with options to try to "Overwrite", "Save as" or "Revert" the changes.