Conflict Detection false positives

[Derek Wiers]

When I have conflict detection on for dedicated logins, I get this pop-up (attached) upon save/deploy of a class sometimes. I get that the last modified user was not me, but I wasn't even at this company in 2013, let alone having this repository that long (this sandbox in question was only even refreshed in April 2016), and I had refreshed my local repository today. We're not using version control as of yet (been on a long list of things I've been wanting to do...), but shouldn't the IDE be able to detect conflicts with a bit more granularity than that (as in, a LastModifiedDate that is after the last time I refreshed my repo, or saved this file, whichever is later?

[Derek Wiers]

For clarification, it's not just this class - this is just an example of a common issue I've been having.

[Scott Wells]

Derek, for Dedicated Logins IC reports a conflict when the last modifier reported by the org is not the same as the user specified in the IC connection. It sounds like this can yield false positives when you retrieve metadata from the org that was modified by other users before the retrieval, then you try to deploy changes to those files and it thinks that someone else edited it last. I think this is what you're seeing here. As you've suggested, this issue could be solved by only reporting conflicts if the last modified date is more recent than the last retrieval/successful deployment date (which is actually how it works when configured for Shared Logins).

I'll look at adding that to the conflict detection logic to make it more robust. Please let me know if I've misinterpreted the issue so that I can make sure I'm addressing the right problem!

Thanks for the info, Scott

[Derek Wiers]

yeah, adding logic like what you've described above would help. I think we're on the same page. However, even if you have dedicated logins like in my org, why do we need to figure out what user last modified it? If they last modified it after my last retrieval or deploy, then it would be a conflict. To put it into logic (sorry for the crappy pseudocode):

if (classOnServer.lastModifiedDate > (Math.Max(localClass.lastRetrievedDate, localClass.lastDeployedDate)) {
    alert(conflict);
}

Ultimately, it shouldn't matter who edited the file last, because even if I myself update the code via the Salesforce UI (which would be weird, but has happened before), then forget to refresh - that would facilitate a conflict, even though only my username was involved. It's just LastModifiedDate. Make sense? It sounds like Shared Logins does this already, so I think in the meantime I'll just be using Shared Logins as an option instead.

[Scott Wells]

Derek, what you're describing is pretty much exactly how the Shared Logins option works today. You should be able to switch to that conflict detection model to use it. The issue with that model is the narrow window of opportunity for a false positive/negative when comparing local timestamps to (timezone-adjusted) server timestamps. I take several samples of the server-reported time to get a good delta between local and server for comparison, but because of network latency when making API calls to query the server for its time, it's not 100% perfect. As a result, checking the last modifier pretty much eliminates that potential for false reports, though it introduces the issue with seeing older modifications as conflicts. Using the server last modified date as a second-pass filter should resolve that completely, though, since you're not trying to do millisecond-level comparisons, just whether it was really last modified in a recent session by another user.

Hopefully that clarifies the pros and cons of each approach. For what it's worth, I've given feedback to Salesforce that some form of first-class conflict detection would be a welcome addition for Tooling purposes. Hopefully it'll get added.

[Derek Wiers]

ah, gotcha. Thanks for the clarification. I'll use the Shared Logins - it's only me and 1 other developer who's ever really doing significant changes in code at any given time, and we have other (home grown :( ) tools to keep us from modifying the same file at the same time, which should drastically minimize millisecond-level issues. When I was typing my explanation above, I was wondering about 'fuzzy logic' when it came to exact save times at the millisecond-to-a-few-second range.

Here's an idea - I figure it's probably not practical for performance reasons (the overhead on this would probably be a tad ridiculous), but I figure I'd put it out here anyway: If, during the save/deploy operation, you have the previously saved (local) version of the file available (which I figure you would due to IntelliJ's extensive local history feature), is it at all feasible to compare that with the Server's version? My guess is no because that would involve doubling each save call - retrieve current server version, check if equals, then save...But I figure it's worth a shot.

Thanks for all the info! it's been awesome!

[Scott Wells]

That's the right idea. In a perfect world I'd have access to CRCs or modcounts (vs. mod timestamps) of all metadata from the server that I could retrieve efficiently at session startup and update during deploy/retrieve operations. That way I could see whether the CRC/modcount of a file to be deployed has changed from its last known good state and avoid the client/server timestamp difference issue. Unfortunately that's not available right now, so I landed on these two options. I think by adding the check against last modified time in the Dedicated Logins option I'll likely have as good a solution as is possible right now...at least with any efficiency.

[Derek Wiers]

ah, right. That makes sense. Makes me wonder what MavensMate is doing (I was a MM/Sublime user prior to IC...never had a false positive on conflicts, but then, I don't know that I deployed within 500ms or whatever of someone else modifying the same file...)

[Scott Wells]

Need to look at issue #636 when looking at this.

[Doug Ayers]

Issue #636 was marked as a duplicate of this issue.

[Scott Wells]

Delivered in 1.8.0.4.