Conflict found during build, but no merge options shown

[Kamil Murawski]

Hi,

I've got a problem with conflict check when saving a single file.

Reproduction steps:

1. A retrieves class XXX

2. B makes changes to class XXX

3. B deploys class XXX

4. A makes changes to class XXX

5. A deploys class XXX

Expected:

5. Conflict found, merge options window appears

Actual:

5. No conflict found, changes of B in class XXX are overwritten

I'm working on a single org with another developer. We both have dedicated logins, both use Illuminated Cloud, both have Conflict check set on Dedicated logins.

I have checked the logs (see attachment), and the conflict is actually detected and the class is marked to be merged.

Any ideas?

Thanks, Kamil

[Scott Wells]

Thanks for reporting! That certainly looks like a bug. I'll take a look very shortly.

[Kamil Murawski]

Hi, any update on this issue?

Thanks!

[Scott Wells]

Because of the Summer '18 release I have not been able to look at this yet. I will try to do so for next week's build.

[Scott Wells]

Kamil, I've been unable to reproduce this locally, but I did find something that may well be contributing to the issue. I found a bug in the way that I'm computing and storing the relevant timestamps when you retrieve metadata if the server and the local machine(s) are in different timezones. That may or may not be contributing to your issue, but the other thing I've done is supplemented the debug logging in between these two stanzas from the provided log:

2018-06-04 13:19:54,045 [15296960]  DEBUG - tellij.builder.ForceComBuilder - The following files need to be merged: 
2018-06-04 13:19:54,045 [15296960]  DEBUG - tellij.builder.ForceComBuilder - classes/xxx.cls - last modified by B (B@B) on Mon Jun 04 13:19:40 CEST 2018 
...
2018-06-04 13:19:54,045 [15296960]  DEBUG - der.ForceComToolingApiDeployer - Creating any missing metadata before saving with the Tooling API. 

in hopes of seeing better why this might be happening to you assuming that the aforementioned fix doesn't address it.

[Scott Wells]

Prospective fix delivered in 1.8.3.3 and 2.0.2.6. This includes a fix for the way that the timestamps used for dirty/conflict detection are computed as well as more extensive debug logging in the area where the problem seems to be occurring.

After updating, I'd recommend that you perform a retrieve and/or deploy of your project to ensure things are properly in sync and those timestamps are computed properly, then see if the problem still occurs. If it does, please capture a new debug log, attach it here, and reopen the issue so that I can investigate further.

[Kamil Murawski]

Awesome! Thanks for the great support, I'll update IC and check it out soon.

[Scott Wells]

Sounds good. And like I said, it's VERY possible this doesn't fix your issue (though it does fix an issue), but it should give much more diagnostic info when the problem occurs.