Conflict detection for multiple users with a single login

Issue #152 resolved
Scott Wells repo owner created an issue

Some users have requested conflict detection when collaborating in a shared org using a single set of credentials. Current conflict detection assumes that each user has a distinct login.

The thing that makes this complicated vs. just looking to see if another user has modified the metadata in the org is that you really need three pieces of information:

  1. The timestamp of the metadata when it was retrieved into the local project.
  2. The timestamp of the metadata when it's being requested for deployment from the local project into the org.
  3. The timestamp of the metadata in the local project (for incremental deployment). I have 2 and 3 now and use them for smart incremental deployment. To make single user collision detection work properly, I'll also need 1, hence the need to establish a baseline.

Once that baseline has been established--likely by prompting the user to perform a full project retrieve, capturing the timestamp info, and asking the user to reconcile local vs. remote before the next deployment--I don't think another will be needed again unless the user explicitly wants to do so.

After that I should be able to keep track of all three items above as long as the plugin is being used for all deployment into the org. On deployment I'll basically say that if 3 > 1, the metadata is a candidate for deployment (this is how I do incremental deployment today), and if 2 > 1, it's also a potential conflict and the user should be prompted to merge. Then after successful deployment I'd just update 1 based on the new timestamps.

Comments (18)

  1. Matt Addy Account Deactivated

    Scott, has there been any progress on this? I was under the impression that the existing "Enable Conflict Checking" feature already checked for conflicts when using a single set of credentials. This is a critical feature for our team. Thanks!

  2. Scott Wells reporter

    Matt, I haven't started on this but was hoping to get to it soon. As you stated, current conflict checking depends on each developer using a distinct login because it's basically looking to see if the metadata requested for deployment was last modified by a different user. As noted above, detecting conflicts when users are sharing credentials is more involved. My best guess is that I'll be able to get to this within the next several weeks.

  3. Scott Wells reporter

    I'm still planning to get to this soon. The past two weeks have been VERY busy for me, but I'm hoping to turn my attention to this and a few other things in the next week or two. Just wanted to let watchers know that this is still very much on my near-term agenda.

  4. Scott Wells reporter

    Okay, I'm back from a week-long business trip but not quite at 100% yet (got stuck overnight in Charlotte due to Snowmageddon and currently operating on ~3 hours of sleep). I'm going to organize this work alongside a few other commitments and see if I can get them resolved soon. Give me a day or two to get things ordered properly and I'll give a revised estimate on delivery of the feature.

  5. Scott Wells reporter

    FYI, this is next in my queue. No guarantees, but hopefully I'll deliver it in the next week or two.

  6. Scott Wells reporter

    Okay, I'm going to call this next-next in the queue. With Spring '16 now rolled out into all orgs, I want to do a quick update for Spring '16 and then I'll knock this one out.

  7. Chris Watson

    I'd just like to give this a big +1. The company I work for is not using Intellij soley because this feature doesn't exist in Illuminated Cloud yet. If it were to be implemented I think I could convince a lot of people to switch from Eclipse and Welkin and you'd make quite a bit off our switch

  8. Scott Wells reporter

    Good timing, Chris! I'm starting work on it right now...this time for real! I finally managed to clear the deck of other deployment enhancements and various bug fixes and can focus on this 100% now. My hope is to get it out early next week, though as always that will depend on incoming interrupts.

  9. Scott Wells reporter

    Quick update on this...it's just about feature complete. I have a few small bugs to address around static resource and lightning bundles and then want to test it heavily. I'm thinking I'll be releasing it on Monday along with a few other small items. The final implementation is actually quite seamless with no real onus on the developer to establish a base state as described above.

  10. Scott Wells reporter

    Okay, here's a test build with shared login conflict detection if you guys want to give it a whirl. After you download and install the plugin from disk, all you have to do is enable conflict detection for your connection with shared (vs. dedicated) logins:

    SharedLoginConflictDetection.png

    Once enabled, you won't be able to use Deploy Modified Metadata any longer because there's no good way to know whether timestamp differences locally vs. the org actually indicate something being out-of-date, but that's the only real limitation.

    It compares successful build times to server last modified times to determine dirtiness, and the build times are updated when a metadata file is successfully deployed to the server or retrieved from the server (NOTE: it's updated even if the file is not copied into the local source root in the directory diff tool; I have no way of tracking that, especially with external diff tools).

    It works with standard metadata files as well as static resource bundles and Lightning components. I've noticed on the latter that sometimes the last mod time reported by Salesforce is within the sub-second margin of error of the locally-recorded time and you'll get a false conflict. I'll work on that when I spend more time on Lightning (finally next on deck after this!).

    I'll likely release this broadly on Monday. Installing the test build won't interfere with the upgrade to the official build. If you try it out, please let me know whether it's working properly for you or not!

  11. Log in to comment