@salesforce/plugin-deploy-retrieve 1.8.6 → 1.8.7

package/messages/deploy.async.md

@@ -8,12 +8,12 @@ Deploy has been queued for cancellation.
 
 # info.AsyncDeployCancel
 
-Run "sf deploy metadata cancel --job-id %s" to cancel the deploy.
+Run "%s project deploy cancel --job-id %s" to cancel the deploy.
 
 # info.AsyncDeployStatus
 
-Run "sf deploy metadata report --job-id %s" to get the latest status.
+Run "%s project deploy report --job-id %s" to get the latest status.
 
 # info.AsyncDeployResume
 
-Run "sf deploy metadata resume --job-id %s" to resume watching the deploy.
+Run "%s project deploy resume --job-id %s" to resume watching the deploy.

package/messages/deploy.md

@@ -12,7 +12,7 @@ For example, if your local project contains a source directory with metadata fil
 
 The command stores your responses in the "deploy-options.json" file in your local project directory and uses them as defaults when you rerun the command. Specify --interactive to force the command to reprompt.
 
-Use this command for quick and simple deploys. For more complicated deployments, use the environment-specific commands, such as "sf deploy metadata", that provide additional flags.
+Use this command for quick and simple deploys. For more complicated deployments, use the environment-specific commands, such as "<%= config.bin %> project deploy start", that provide additional flags.
 
 # examples
 
@@ -84,3 +84,7 @@ Deployer "%s" exited with code %d.
 # save.as.default
 
 Save username %s as default?
+
+# deprecation
+
+The top-level deploy command is deprecated. You should use `functions deploy` to deploy functions, and use `project deploy start` to deploy metadata to Salesforce orgs.

package/messages/deploy.metadata.cancel.md

@@ -26,10 +26,10 @@ Job ID of the deploy operation you want to cancel.
 
 These commands return a job ID if they time out or you specified the --async flag:
 
-- sf deploy metadata
-- sf deploy metadata validate
-- sf deploy metadata quick
-- sf deploy metadata cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -47,7 +47,7 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the cancellation, run "sf deploy metadata resume". To check the status of the cancellation, run "sf deploy metadata report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the cancellation, run "<%= config.bin %> project deploy resume". To check the status of the cancellation, run "<%= config.bin %> project deploy report".
 
 # flags.async.summary
 
@@ -55,8 +55,12 @@ Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the cancellation, run "sf deploy metadata resume". To check the status of the cancellation, run "sf deploy metadata report".
+The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the cancellation, run "<%= config.bin %> project deploy resume". To check the status of the cancellation, run "<%= config.bin %> project deploy report".
 
 # error.CannotCancelDeploy
 
 Can't cancel deploy because it's already completed.
+
+# error.CannotCancelDeployPre
+
+Can't cancel deploy with Job Id %s because it's already completed (status is %s)

package/messages/deploy.metadata.md

@@ -56,6 +56,18 @@ To deploy multiple metadata components, either set multiple --metadata <name> fl
 
 Login username or alias for the target org.
 
+# flags.pre-destructive-changes.summary
+
+File path for a manifest (destructiveChangesPre.xml) of components to delete before the deploy
+
+# flags.post-destructive-changes.summary
+
+File path for a manifest (destructiveChangesPost.xml) of components to delete after the deploy.
+
+# flags.purge-on-delete.summary
+
+Specify that deleted components in the destructive changes manifest file are immediately eligible for deletion rather than being stored in the Recycle Bin.
+
 # flags.target-org.description
 
 Overrides your default org.
@@ -98,7 +110,7 @@ Number of minutes to wait for command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume the deployment, run "sf deploy metadata resume". To check the status of the deployment, run "sf deploy metadata report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume the deployment, run "<%= config.bin %> project deploy resume". To check the status of the deployment, run "<%= config.bin %> project deploy report".
 
 # flags.manifest.summary
 
@@ -166,7 +178,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume the deployment, run "sf deploy metadata resume". To check the status of the deployment, run "sf deploy metadata report".
+The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume the deployment, run "<%= config.bin %> project deploy resume". To check the status of the deployment, run "<%= config.bin %> project deploy report".
 
 # flags.metadata-dir.summary
 
@@ -191,7 +203,7 @@ You must specify tests using the --tests flag if the --test-level flag is set to
 
 # error.ClientTimeout
 
-The command has timed out, although the deployment is still running. Use "sf deploy metadata resume" to resume watching the deployment.
+The command has timed out, although the deployment is still running. Use "%s project deploy resume" to resume watching the deployment.
 
 # error.Conflicts
 
@@ -201,7 +213,7 @@ There are changes in the org that conflict with the local changes you're trying
 
 - To overwrite the remote changes, rerun this command with the --ignore-conflicts flag.
 
-- To overwrite the local changes, run the "sf retrieve metadata" command with the --ignore-conflicts flag.
+- To overwrite the local changes, run the "%s project retrieve start" command with the --ignore-conflicts flag.
 
 # error.nothingToDeploy
 
@@ -209,4 +221,24 @@ No local changes to deploy.
 
 # error.nothingToDeploy.Actions
 
-- To see conflicts and ignored files, run "sf deploy metadata preview" with any of the manifest, directory, or metadata flags.
+- To see conflicts and ignored files, run "%s project deploy preview" with any of the manifest, directory, or metadata flags.
+
+# flags.junit.summary
+
+Output JUnit test results.
+
+# flags.coverage-formatters.summary
+
+Format of the code coverage results.
+
+# flags.results-dir.summary
+
+Output directory for code coverage and JUnit results; defaults to the deploy ID.
+
+# asyncCoverageJunitWarning
+
+You requested an async deploy with code coverage or JUnit results. The reports will be available when the deploy completes.
+
+# pushPackageDirsWarning
+
+The `pushPackageDirectoriesSequentially` property is not respected by this command. Please call the `project deploy start --source-dir` command for each dependency in the correct order.

package/messages/deploy.metadata.preview.md

@@ -6,7 +6,7 @@ Preview a deployment to see what will deploy to the org, the potential conflicts
 
 You must run this command from within a project.
 
-The command outputs a table that describes what will happen if you run the "sf deploy metadata" command. The table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be deployed because they're included in your .forceignore file.
+The command outputs a table that describes what will happen if you run the "<%= config.bin %> project deploy start" command. The table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be deployed because they're included in your .forceignore file.
 
 If your org allows source tracking, then this command considers conflicts between the org and local. Some orgs, such as production orgs, never allow source tracking. Use the "--no-track-source" flag when you create a scratch or sandbox org to disable source tracking.
 
@@ -14,15 +14,15 @@ To preview the deployment of multiple metadata components, either set multiple -
 
 # examples
 
-- NOTE: The commands to preview a deployment and actually deploy it use similar flags. We provide a few preview examples here, but see the help for "sf deploy metadata" for more examples that you can adapt for previewing.
+- NOTE: The commands to preview a deployment and actually deploy it use similar flags. We provide a few preview examples here, but see the help for "<%= config.bin %> project deploy start" for more examples that you can adapt for previewing.
 
-- Preview the deployment of source files in a directory, such as force-app:
+- Preview the deployment of source files in a directory, such as force-app, to your default org:
 
       <%= config.bin %> <%= command.id %>  --source-dir force-app
 
-- Preview the deployment of all Apex classes:
+- Preview the deployment of all Apex classes to an org with alias "my-scratch":
 
-      <%= config.bin %> <%= command.id %> --metadata ApexClass
+      <%= config.bin %> <%= command.id %> --metadata ApexClass --target-org my-scratch
 
 - Preview deployment of a specific Apex class:
 
@@ -36,6 +36,10 @@ To preview the deployment of multiple metadata components, either set multiple -
 
 Login username or alias for the target org.
 
+# flags.only-ignored.summary
+
+Preview files to be ignored in a deployment.
+
 # flags.target-org.description
 
 Overrides your default org.
@@ -64,7 +68,7 @@ All child components are included. If you specify this flag, don’t specify --m
 
 # flags.ignore-conflicts.summary
 
-Ignore conflicts and deploy local files, even if they overwrite changes in the org.
+Don't display conflicts in preview of the deployment.
 
 # flags.ignore-conflicts.description
 
@@ -90,4 +94,4 @@ There are changes in the org that conflict with the local changes you're trying
 
 - To overwrite the remote changes, rerun this command with the --ignore-conflicts flag.
 
-- To overwrite the local changes, run the "sf retrieve metadata" command with the --ignore-conflicts flag.
+- To overwrite the local changes, run the "%s project retrieve start" command with the --ignore-conflicts flag.

package/messages/deploy.metadata.quick.md

@@ -4,7 +4,7 @@ Quickly deploy a validated deployment to an org.
 
 # description
 
-Before you run this command, first create a validated deployment with the "sf deploy metadata validate" command, which returns a job ID. Validated deployments haven't been deployed to the org yet; you deploy them with this command. Either pass the job ID to this command or use the --use-most-recent flag to use the job ID of the most recently validated deployment. For the quick deploy to succeed, the associated validated deployment must also have succeeded.
+Before you run this command, first create a validated deployment with the "<%= config.bin %> project deploy validate" command, which returns a job ID. Validated deployments haven't been deployed to the org yet; you deploy them with this command. Either pass the job ID to this command or use the --use-most-recent flag to use the job ID of the most recently validated deployment. For the quick deploy to succeed, the associated validated deployment must also have succeeded.
 
 Executing this quick deploy command takes less time than a standard deploy because it skips running Apex tests. These tests were previously run as part of the validation. Validating first and then running a quick deploy is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.
 
@@ -36,13 +36,21 @@ Use the job ID of the most recently validated deployment.
 
 For performance reasons, this flag uses only job IDs that were validated in the past 3 days or less. If your most recent deployment validation was more than 3 days ago, this flag won't find a job ID.
 
+# flags.api-version.summary
+
+Target API version for the deploy.
+
+# flags.api-version.description
+
+Use this flag to override the default API version with the API version of your package.xml file. The default API version is the latest version supported by the CLI.
+
 # flags.wait.summary
 
 Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy, run "sf deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy, run "<%= config.bin %> project deploy resume". To check the status of the deploy, run "<%= config.bin %> project deploy report".
 
 # flags.verbose.summary
 
@@ -58,7 +66,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the deploy, run "sf deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".
+The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the deploy, run "<%= config.bin %> project deploy resume". To check the status of the deploy, run "<%= config.bin %> project deploy report".
 
 # flags.target-org.summary
 

package/messages/deploy.metadata.report.md

@@ -26,10 +26,10 @@ Job ID of the deploy operation you want to check the status of.
 
 These commands return a job ID if they time out or you specified the --async flag:
 
-- sf deploy metadata
-- sf deploy metadata validate
-- sf deploy metadata quick
-- sf deploy metadata cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -40,3 +40,15 @@ Use the job ID of the most recent deploy operation.
 # flags.use-most-recent.description
 
 For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less. If your most recent operation was more than 3 days ago, this flag won't find a job ID.
+
+# flags.junit.summary
+
+Output JUnit test results.
+
+# flags.coverage-formatters.summary
+
+Format of the code coverage results
+
+# flags.results-dir.summary
+
+Output directory for code coverage and JUnit results; defaults to the deploy ID.

package/messages/deploy.metadata.resume.md

@@ -26,10 +26,10 @@ Job ID of the deploy operation you want to resume.
 
 These commands return a job ID if they time out or you specified the --async flag:
 
-- sf deploy metadata
-- sf deploy metadata validate
-- sf deploy metadata quick
-- sf deploy metadata cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -47,7 +47,7 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy operation, run this command again. To check the status of the deploy operation, run "sf deploy metadata report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy operation, run this command again. To check the status of the deploy operation, run "<%= config.bin %> project deploy report".
 
 # flags.verbose.summary
 
@@ -60,3 +60,15 @@ Show concise output of the deploy operation result.
 # error.DeployNotResumable
 
 Job ID %s is not resumable with status %s.
+
+# flags.junit.summary
+
+Output JUnit test results.
+
+# flags.coverage-formatters.summary
+
+Format of the code coverage results.
+
+# flags.results-dir.summary
+
+Output directory for code coverage and JUnit results; defaults to the deploy ID.

package/messages/deploy.metadata.validate.md

@@ -4,7 +4,7 @@ Validate a metadata deployment without actually executing it.
 
 # description
 
-Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to "sf deploy metadata", except you're required to run Apex tests, and the command returns a job ID rather than executing the deployment. If the validation succeeds, then you pass this job ID to the "sf deploy metadata quick" command to actually deploy the metadata. This quick deploy takes less time because it skips running Apex tests. The job ID is valid for 10 days from when you started the validation. Validating first is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.
+Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to "<%= config.bin %> project deploy start", except you're required to run Apex tests, and the command returns a job ID rather than executing the deployment. If the validation succeeds, then you pass this job ID to the "<%= config.bin %> project deploy quick" command to actually deploy the metadata. This quick deploy takes less time because it skips running Apex tests. The job ID is valid for 10 days from when you started the validation. Validating first is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.
 
 You must run this command from within a project.
 
@@ -14,7 +14,7 @@ To validate the deployment of multiple metadata components, either set multiple
 
 # examples
 
-- NOTE: These examples focus on validating large deployments. See the help for "sf deploy metadata" for examples of deploying smaller sets of metadata which you can also use to validate.
+- NOTE: These examples focus on validating large deployments. See the help for "<%= config.bin %> project deploy start" for examples of deploying smaller sets of metadata which you can also use to validate.
 
 - Validate the deployment of all source files in a directory to the default org:
 
@@ -72,7 +72,7 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume watching the validation, run "sf deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".
+If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume watching the validation, run "<%= config.bin %> project deploy resume". To check the status of the validation, run "<%= config.bin %> project deploy report".
 
 # flags.manifest.summary
 
@@ -112,7 +112,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume watching the validation, run "sf deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".
+The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume watching the validation, run "<%= config.bin %> project deploy resume". To check the status of the validation, run "<%= config.bin %> project deploy report".
 
 # flags.metadata-dir.summary
 
@@ -126,6 +126,10 @@ Indicates that the metadata zip file points to a directory structure for a singl
 
 Successfully validated the deployment (%s).
 
+# info.suggestedQuickDeploy
+
+Run "%s project deploy quick --job-id %s" to execute this deploy
+
 # error.FailedValidation
 
-Falied to validate the deployment (%s).
+Failed to validate the deployment (%s).

package/messages/list.ignored.md

@@ -0,0 +1,29 @@
+# summary
+
+Check your local project package directories for forceignored files.
+
+# description
+
+When deploying or retrieving metadata between your local project and an org, you can specify the source files you want to exclude with a .forceignore file. The .forceignore file structure mimics the .gitignore structure. Each line in .forceignore specifies a pattern that corresponds to one or more files. The files typically represent metadata components, but can be any files you want to exclude, such as LWC configuration JSON files or tests.
+
+# examples
+
+- List all the files in all package directories that are ignored:
+
+  <%= config.bin %> <%= command.id %>
+
+- List all the files in a specific directory that are ignored:
+
+  <%= config.bin %> <%= command.id %> --source-dir force-app
+
+- Check if a particular file is ignored:
+
+  <%= config.bin %> <%= command.id %> --source-dir package.xml
+
+# flags.source-dir.summary
+
+File or directory of files that the command checks for foreceignored files.
+
+# invalidSourceDir
+
+File or directory '%s' doesn't exist in your project. Specify one that exists and rerun the command.

package/messages/manifest.generate.md

@@ -0,0 +1,74 @@
+# summary
+
+Create a project manifest that lists the metadata components you want to deploy or retrieve.
+
+# description
+
+Create a manifest from a list of metadata components (--metadata) or from one or more local directories that contain source files (--source-dir). You can specify either of these parameters, not both.
+
+Use --type to specify the type of manifest you want to create. The resulting manifest files have specific names, such as the standard package.xml or destructiveChanges.xml to delete metadata. Valid values for this parameter, and their respective file names, are:
+
+    * package : package.xml (default)
+    * pre : destructiveChangesPre.xml
+    * post : destructiveChangesPost.xml
+    * destroy : destructiveChanges.xml
+
+See https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm for information about these destructive manifest files.
+
+Use --name to specify a custom name for the generated manifest if the pre-defined ones don’t suit your needs. You can specify either --type or --name, but not both.
+
+To include multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --include-packages and --source-dir.
+
+# examples
+
+- Create a manifest for deploying or retrieving all Apex classes and custom objects:
+
+  $ <%= config.bin %> <%= command.id %> --metadata ApexClass --metadata CustomObject
+
+- Create a manifest for deleting the specified Apex class:
+
+  $ <%= config.bin %> <%= command.id %> --metadata ApexClass:MyApexClass --type destroy
+
+- Create a manifest for deploying or retrieving all the metadata components in the specified local directory; name the file myNewManifest.xml:
+
+  $ <%= config.bin %> <%= command.id %> --source-dir force-app --name myNewManifest
+
+- Create a manifest from the metadata components in the specified org and include metadata in any unlocked packages:
+
+  $ <%= config.bin %> <%= command.id %> --from-org test@myorg.com --include-packages unlocked
+
+# flags.include-packages.summary
+
+Package types (managed, unlocked) whose metadata is included in the manifest; by default, metadata in packages is ignored.
+
+# flags.from-org.summary
+
+Username or alias of the org that contains the metadata components from which to build a manifest.
+
+# flags.type.summary
+
+Type of manifest to create; the type determines the name of the created file.
+
+# flags.name.summary
+
+Name of a custom manifest file to create.
+
+# flags.output-dir.summary
+
+Directory to save the created manifest.
+
+# flags.source-dir.summary
+
+Paths to the local source files to include in the manifest.
+
+# flags.metadata.summary
+
+Names of metadata components to include in the manifest.
+
+# success
+
+successfully wrote %s
+
+# successOutputDir
+
+successfully wrote %s to %s

package/messages/retrieve.metadata.md

@@ -14,13 +14,13 @@ To retrieve multiple metadata components, either use multiple --metadata <name>
 
 # examples
 
-- Retrieve remote changes:
+- Retrieve remote changes from your default org:
 
   <%= config.bin %> <%= command.id %>
 
-- Retrieve the source files in a directory:
+- Retrieve the source files in a directory from an org with alias "my-scratch":
 
-  <%= config.bin %> <%= command.id %> --source-dir path/to/source
+  <%= config.bin %> <%= command.id %> --source-dir path/to/source --target-org my-scratch
 
 - Retrieve a specific Apex class and the objects whose source is in a directory (both examples are equivalent):
 
@@ -157,7 +157,7 @@ There are changes in your local files that conflict with the org changes you're
 
 - To overwrite the local changes, rerun this command with the --ignore-conflicts flag.
 
-- To overwrite the remote changes, run the "sf deploy metadata" command with the --ignore-conflicts flag.
+- To overwrite the remote changes, run the "%s project deploy start" command with the --ignore-conflicts flag.
 
 # info.WroteZipFile
 

package/messages/retrieve.metadata.preview.md

@@ -6,19 +6,19 @@ Preview a retrieval to see what will be retrieved from the org, the potential co
 
 You must run this command from within a project.
 
-The command outputs a table that describes what will happen if you run the "sf retrieve metadata" command. The table lists the metadata components that will be retrieved and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be retrieved because they're included in your .forceignore file.
+The command outputs a table that describes what will happen if you run the "<%= config.bin %> project retrieve start" command. The table lists the metadata components that will be retrieved and deleted. The table also lists the current conflicts between files in your local project and components in the org. Finally, the table lists the files that won't be retrieved because they're included in your .forceignore file.
 
 If your org allows source tracking, then this command considers conflicts between the org and local. Some orgs, such as production orgs, never allow source tracking. Use the "--no-track-source" flag when you create a scratch or sandbox org to disable source tracking.
 
 # examples
 
-- Preview the retrieve of all changes from the org:
+- Preview the retrieve of all changes from your default org:
 
   <%= config.bin %> <%= command.id %>
 
-- Preview the retrieve when ignoring any conflicts:
+- Preview the retrieve when ignoring any conflicts from an org with alias "my-scratch":
 
-  <%= config.bin %> <%= command.id %> --ignore-conflicts
+  <%= config.bin %> <%= command.id %> --ignore-conflicts --target-org my-scratch
 
 # flags.target-org.summary
 
@@ -30,7 +30,7 @@ Overrides your default org.
 
 # flags.ignore-conflicts.summary
 
-Ignore conflicts and preview the retrieve of remote components, even if they will overwrite local changes.
+Don't display conflicts in the preview of the retrieval.
 
 # flags.ignore-conflicts.description
 
@@ -54,6 +54,6 @@ There are local changes that conflict with the remote changes that would be retr
 
 # error.Conflicts.Actions
 
-- To overwrite the remote changes, run the "sf deploy metadata" command with the --ignore-conflicts flag.
+- To overwrite the remote changes, run the "project deploy start" command with the --ignore-conflicts flag.
 
-- To overwrite the local changes, run the "sf retrieve metadata" command with the --ignore-conflicts flag.
+- To overwrite the local changes, run the "project retrieve start" command with the --ignore-conflicts flag.