salesforcedx-vscode: 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: image

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: image

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.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 10
  • Comments: 35 (9 by maintainers)

Most upvoted comments

@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.

@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

@smaddox-sf just a thought, but is the “Sync” part of “Detect Conflicts at Sync” a little bit off? It seems like “Detect Conflicts on Save/Deploy” would be more appropriate.

Doesn’t look like the sync is happening at least on deploy. I get a conflict every time I make a change to the file and deploy.

Hi @ChuckJonas , @abd3 , @ralphcallaway and @AmrutHunashyal - Thanks for checking back and for your interest in this feature. I’m excited to say that the feature is nearly complete and we plan to move it to GA later this summer!! We’re continuing to ship incremental progress weekly and I will post an update here when it is complete. Here’s the updates we’ve made since I posted the original spec (original post updated to reflect reality as well):

  • A conflict is detected when the last modified date in Org is more recent than the date you last synced this file locally. (The local file could be synced either via a deploy or retrieve)
  • When you enable the ‘Detect Conflicts at Sync’ setting, we will check for conflicts on all Deploy operations (including deploy-on-save)
  • @abd3 - To start, we will surface the list of files with a potential conflict and you can see a Diff on each. Options from there will be to choose to do retrieve(s) or rerun the deploy with an overwrite. In the future, we may consider adding further sophistication on the resolution after potential conflicts are surfaced.

@smaddox-sf any idea when this will be rolled out ?

Hi,

I just raised a bug for this. https://github.com/forcedotcom/salesforcedx-vscode/issues/2604

Thank you very much.

Kind regards,

On Mon, Oct 5, 2020 at 5:35 PM smaddox-sf notifications@github.com wrote:

HI @DaniyelShchuritz https://github.com/DaniyelShchuritz - Can you open a new issue (type: Bug) https://github.com/forcedotcom/salesforcedx-vscode/issues/new?template=Bug_report.md with the details so we can check into it? This “issue” is the spec for feedback and it’s easier to discuss 1 topic per issue versus mixing them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/forcedotcom/salesforcedx-vscode/issues/2034#issuecomment-703746830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4PQTX2IYFJHWQ3FUU2JMTSJHYV5ANCNFSM4K3QASDQ .

Danijel