Salesforcedx-vscode: Conflict Detection - Next iteration - Spec for feedback

[smaddox-sf]

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. Conversely, when a user retrieves metadata from an org conflicts with the local source should be checked as well to ensure local changes won't be overwritten. 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.

Vision for the next iteration:
We will expand to all Deploy & Retrieve commands and add some intelligence. To determine potential conflicts, we will look at the last modified date. 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 (or retrieval) via the CLI sfdx force:source:deploy/retrieve ... --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 or retrieve 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 or retrieve 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/retrieve 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.

[abd3]

It might be helpful if there was an affordance for each file, like a button allowing you to "keep local version" or "keep remote version". You should also be explicit in each pane, whether it's the local version or the remote version if possible; that can get confusing for users.

This is a somewhat separate issue, but it's a major challenge that the metadata API allows users to retrieve or deploy metadata that's part of an unlocked package without giving any warning that you're modifying the contents of the package. If there was a way to flag or warn if you were overwriting the contents of an unlocked package, that could help users keep the integrity of the packages. They should make those changes in the package, not directly in the org.

[smaddox-sf]

Thanks for the feedback @abd3! It's useful to know what would help your team. Regarding labeling the panels, it's a bit small in the screenshot above, but the titlebar has the org alias prefixed on the left and 'local' prefixed on the right. Perhaps this isn't discoverable enough?

The input regarding packages is interesting. We'll consider that area in the future.

[abd3]

I see it now that I'm looking at the image in fullscreen. My intuition says that the local copy should be on the left, with the idea that your goal is to send to the target org on the right (left to right flow), but others may think differently

[digiur]

Does this work for all metadata files?

[smaddox-sf]

@digiur - Yes, will work for all files you Deploy & Retrieve

[amnezhdez]

Thank you for the job, it's a very useful functionality.

It might be helpful if there was a configuration, to select some changes to ignore them. For example, ignore conflicts in minor changes, such as description or help text.

[AmrutHunashyal]

Hi @smaddox-sf can you please let us know when Diff Detection would be available (even beta) for Deploy & Retrieve source to/from org. thanks.

[smaddox-sf]

Hi @AmrutHunashyal - I'm glad you're looking forward to this feature! Our goal is to have it ready for all deploy / retrieve commands within about 6 months. Feel free to check out our roadmap to see what we're working on.

[DaniyelShchuritz]

Hi @smaddox-sf, this is still not working for me.

1. I've enabled the Detect Conflicts At Sync in my VS Code
2. Change the apex class directly on the org and save it
3. Change the same class locally with my VS Code
4. Run this command
   sfdx force:source:deploy -x manifest/Sprint.xml -u myOrg --verbose

And it deploys successfully and overrides the changes I created directly on the org without mentioning any conflicts.
Am I doing something wrong?

Many thanks!

[smaddox-sf]

HI @DaniyelShchuritz - Can you open a new issue (type: Bug) 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.

[DaniyelShchuritz]

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 [e-mail] 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

[AmrutHunashyal]

@smaddox-sf

[Hi @AmrutHunashyal - I'm glad you're looking forward to this feature! Our goal is to have it ready for all deploy / retrieve commands within about 6 months.]

It's been 6 months, any update on this ?

[smaddox-sf]

Hi @AmrutHunashyal - Thanks for checking back. We've completed the foundational libraries needed to make this feature performant. Things have taken longer than originally thought. This is still planned as near-term work.

[chasd00]

Thanks for working on this, i've been fighting code overwrite problems in my teams and finally found out some users are using SFDX commands for deployment in VSCode while others are using forcecode deploy-on-save (which gives a warning). Any update on when the next iteration will be released? I'm very interested in this feature applied to non-manifest deployments.

[ralphcallaway]

in my experience most people are using the deploy on save functionality

"salesforcedx-vscode-core.push-or-deploy-on-save.enabled": true

if that's not covered by the current version, i think that's a must

and if it is covered by the current version please let me know, because it's not working, and i need to file a bug

[chasd00]

Can we get an update on when the next iteration can be expected? I have a team of 25 devs and leadership+client is getting pretty upset when i have to give yet another update "...we're dealing with a code overwrite issue.." heh

[smaddox-sf]

Hi @chasd00 - Thanks for checking back on this. I'm sorry your team is continuing to have overwrite issues. We will start working on the completion of this feature later this month. We haven't done planning yet, so I don't have an ETA on release just yet.

@ralphcallaway - Question for you on deploy-on-save - Right now, Diff Detection doesn't have much intelligence. It is simply telling you any difference between what you are deploying & the org (including your own change). This means it would prompt you each time you save, even if no one else has changed the file. Do you think it would still be helpful to your team in that state?

[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 @ChuckJonas that's a great way to go, one suggestion

• don't update the timestamp on save
• whenever a remote save (i.e. deployment, creation) succeeds, retrieve the resulting metadata
• whenever you retrieve metadata, update the local timestamp with the remote timestamp

[ralphcallaway]

beyond making sure the timestamps are exact and you don't have to think about thresholds for save time, it has the added benefit of ensuring the metadata in your editor matches what's on salesforce exactly

[ralphcallaway]

@smaddox-sf this would need to happen for every save route in vscode, so you'd want to hook in at the lowest level possible

from there, you'll need 1) a force option, and 2) a diff viewer to merge conflicts (nice to have if you're time strapped)

[AmrutHunashyal]

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