Conflict Detection - Next iteration - Spec for feedback

I’m posting the details of our next iteration on the Conflict Detection feature. Check out the plans and leave a comment if you have input

Problem we are seeking to solve: When a user deploys metadata to the org, VS Code should check to ensure that the local metadata changes won’t silently overwrite changes on the org. This only applies to orgs without source tracking (such as sandboxes).

Current beta: The open beta for the first iteration of this feature is available. Check it out and see the details in our documentation. With this version, you can choose to detect differences for manifests only. When a difference is detected between the Org & local project, you see a list of files with differences in the Output panel. If you want to override, you are given the command to execute. This is strictly doing a diff between your local and the org. The beta applied to both deploy & retrieve with a manifest.

Vision for the next iteration: We will expand to all Deploy commands and add some intelligence to do more than just a diff. To determine potential conflicts, we will look at the last modified date in the Org and the date you last synced the local file. If the date is more recent on the file in the org, we will include this as a potential conflict. When any potential is detected, you have an option to view the details or overwrite immediately. If you choose the ‘Overwrite’ option, it will be the same as forcing the deployment via the CLI sfdx force:source:deploy ... --force.

Illustration of the new dialog that appears when differences are detected:

If you choose to ‘Show Conflicts’, you will see the list of conflicted files via a temporary tab on the side panel. You can click each file to see a diff between the local version and the org version at the time the deploy was executed. While viewing the diff, you can edit the local version.

Note: This view will not persist if you close the project or close VS Code. (However, you can see the view again by running another deploy command or a Diff command.)

Illustration of the potential view of conflicted files:

After you review the potential conflicts, it’s up to you to continue with the deploy and force an overwrite or perhaps take other actions to resolve conflicts.

This feature is controlled by a VS Code setting, ‘Detect Conflicts at Sync’. That setting is off by default.

If you want to check for differences before a retrieve, use Source Diff.

[ChuckJonas]

@smaddox-sf having it just diff local vs remote won’t help anything (as you already pointed out).

You need to track the Salesforce ApexClass.LastModifiedDate locally in the project:

MyApexClass -> 1601332000000,
MyObject__c -> 1601532000000

This table would get updated anytime you save or retrieve code.

When you go to deploy metadata, you would:

1. Grab the Local Timestamp from the table & the content from the editor
2. Query the current Timestamp & Content from the target org
3. Compare Timestamps -> Compare Code -> Display warning

local = getTimestampAndContent()
remote = [SELECT LastModifiedDate, Content FROM ApexClass Where ID = :local.Id];
IF  local.Timestamp < current.Timestamp THEN 
   diff_Count = Diff_Files(local.Content, remote.Content);
   IF diff_Count > 0 THEN Display_Warning()

For reference, this is how mavensmate did it. Basically the solution above, with an additional “dirty” flag.

[ralphcallaway]

@smaddox-sf excited to see progress, but i think you might want to roll this one back.

as it’s implemented this would be better described as a save confirmation dialog. with it on, every save that changes anything (which is pretty much all of them, since what’s the point of saving something that’s the same as what’s on the server), regardless of whether there have been changes on the server or not, sf generates this error message.

as analogy, you open a document, make some changes, save. oh wait conflict? oh i guess the version i started is different with than what i have now, but isn’t that the whole point? I opened it with the intention of making changes, why would the system be surprised and complain about me making changes?

here’s a little video i put together https://youtu.be/Dv95mF22qX8

my $.02, disable this feature asap, as it stands anyone who has this on is going to immediately hate due to the annoying number of pop ups mentioning conflicts that aren’t really conflicts at all

as mentioned previously, there are several models, i.e. mm, that have implemented this successful for salesforce projects. i’d highly suggest starting with their setup as a design