Deploy Modified Metadata is showing non-modified files

[hub...@gmail.com]

First of all, thank you for a great product, I enjoy it more and more every day I am evaluating and I'm definitely going to buy it after the trial;)

I see one issue I can't handle.

We have a git repository with the latest version of our code.

I have created a project out of the repository and 'transformed' it into the IlluminatedCloud project without any problems.

The git code in the repo contains some changes, so I was planning to Deploy Modified Components using the tool.

The issue is that the Select Deployment Scope Window is showing the components that are in scope which is good (I select the ones that I have locally and the ones that are both Local and Server).

When I retrieve, I get diff window like this where I can choose what I want to do with the differences :

When I try to deploy the modified, it seems it tries to find out the differences, but the diff window is not showing and it actually starts to build my whole project (3000+ items) instead of trying just 70 that are a subject of changes.

Maybe I am doing something wrong?

[hub...@gmail.com]

FYI - git diff shows no problems with line endings, and when I do manual diff on the files while comparing, it shows no differences

[Scott]

Glad you're finding the product useful!  Let's see if I we can figure out why it's not calculating the out-of-date files properly...  First, I'd recommend that you add the following under Help>Debug log settings to get full debug logging for the relevant feature:

#com.illuminatedcloud.intellij.builder.ForceComBuilder

That should show you the calculated last modified times locally and on the server and therefore why it's choosing each file for deployment.  My guess is that when you sync the project from git, the local filesystem timestamps from the VCS operation make files look newer than their corresponding entries in the org.

In a perfect world I'd prefer not to use timestamps at all for this or for conflict detection, instead using server-computed CRCs or similar, but unfortunately there's not an efficient way to query the CRCs for all metadata for comparison to locally-computed CRCs.  As a result, (time zone-adjusted) timestamps are the best information I have in making this decision.  There is one bug filed on that, in particular for conflict detection but it might well apply to incremental deployment as well:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/492/conflict-detection-false-positives

Feel free to shoot me the debug log (available via Help>Show Log in Explorer/Finder), but I'd definitely recommend you scan it first since you're more familiar with the disposition of these files than I would be and could likely understand the invalid conclusions it's reaching better.

Best regards,

Scott Wells

[Scott]

You may have the integrated diff tool configured to ignore line endings and/or other white space.  I can't remember what the default settings are off the top of my head.  Either way, the decision to include the file or not is based on timestamp comparisons and not content comparisons.  Please let me know what you see in the debug log.  FYI, I'm going to be out-of-pocket for a few hours but will check back in when I'm available again.

Regards,

Scott

[hub...@gmail.com]

Hi Scott, thank you for your response.

You are right and the timestamp decides that all files are being deployed.

I think I will just stick to build everything or custom pack. In my case the flows (that you cannot simply overwrite, you can either remove all -> deploy all or deploy them incrementally) and some bad data on the profiles are the issue, I think that I might either filter those out with the Substitution Rules in the module settings or fix this somehow in my repo.

I think that for the future, instead of timestamps, you could simply diff the files exactly the way you are currently doing it with retrieve operation, this way it would only show us the files that should actually be deployed.

Thank you very much for your help, much appreciated!

[Scott]

If you perform a single deployment of everything you care about, IC will store the timestamps for future operations so that only things that have changes since the last successful deployment will be included.  It's a one-time cost that pays dividends.

As for performing a diff, the issue is that you then put a retrieval in the critical path for a deployment...in particular for a deployment that's intended to be more efficient by design.  Retrievals always use the metadata API and can vary widely in response time whereas deployments for supported metadata types can use the tooling API which is considerably faster.  That's the main reason I decided not to use retrieved metadata when checking for out-of-date metadata.  There are other reasons, though...a simple diff could decide that "unimportant" changes such as end-of-line differences between Salesforce and the local filesystem would always constitute dirtiness.  Also, it's possible in an org where multiple users are collaborating that one user could accidentally overwrite/undo another user's changes leading to false positives or negatives.

I've actually provided feedback to Salesforce that some type of server-provided mechanism for both dirtiness checks and conflict detection would be very welcome as there's no perfect way to do it right now.

Regards,

Scott