Move and Overwrite is causing file to be deleted from source

[Mike Wannamaker]

So I’ve retrieved a changeset for a project from a sandbox.  There is a file in the changeset a flexipage that when I try to move it, the file becomes deleted. I don’t think it has anything to do with the changeset though. It’s just a file with same name in another non source directory.

I retrieve the changeset and convert it to sfdx format.  Then I just drag it to my flexipage source directory where the same file already exists and I get the following.

I click Overwrite and I then get this:

‌

I haven’t even been successful to push yet, so I usually just say No, and I would normally say No even if I had already pushed because I don’t want it deleted from the org.  But the same behaviour happens whether I push Yes or No.

When I click no, immediately the file is noted as being deleted in the git UI?

‌

I can’t get this behaviour to not happen, which means I’ll have to do my refactoring outside of IC2 and see how it handles it.

‌

Let me know if you need anything else?

[Scott Wells]

Wow, this one was tricky. IC2 listens for key file events to react accordingly. In this case a move/overwrite of an existing file triggers events in the following order:

1. pre-delete on the overwritten file
2. post-delete on the overwritten file.
3. pre-move on the moved file.
4. post-move on the moved file.

As a result, IC2 was processing the move/overwrite target as a delete (steps 1 and 2) with no context that it was about to replaced (not known until step 3). Once I realized that, it wasn't difficult to use the EDT to order event processing so that it happens as follows:

1. pre-move on the moved file which marks the target as being in a move operation.
2. pre-delete on the overwritten file which ignores files that are marked as being in a move operation.
3. post-delete on the overwritten file " " ".
4. post-move on the moved file which unmarks the target as being in a move operation.

Git will still end up with the target file appearing temporarily to be removed and also unversioned, but that's easily remedied by adding the unversioned file to the changelist:

Fix committed for inclusion in the next build.

[Scott Wells]

Delivered in 2.2.2.2.