Mark retrieved files as read-only before comparison

[June Bischoff]

I'm coming from Eclipse with the Force.com IDE, and almost everything about IlluminatedCloud is an improvement except making the adjustment to the retrieval/deployment process. I'm working in a communal sandbox with another developer, so I need to be able to look for changes to any file I'm about to deploy before I deploy it; we used the Force.com synchronize feature exclusively for deploying changes.

Checking for conflicts based on the date before deployment is all well and good, but doesn't show me the diff. If I could push changes to the sandbox using the retrieval comparison tool, that might do the trick, but it doesn't seem like it works that way. What does set copy left (local to sandbox) actually do?

I've also run into issues where I thought I deployed a file, only to discover it didn't go. (I get false errors around @IsTest annotation, so looking for errors on the file isn't foolproof.)

Clear indicators of a dirty file would be a lifesaver. Feel free to break this up into two (or three) tickets if it seems more appropriate.

[June Bischoff]

(Just found the IntelliJ File Status indicator colors, but that only compares to my local copy/git, not to the Sandbox.)

[Scott Wells]

Good feedback, June. You're correct that there's not a clear indicator of dirtiness for a file, particularly with regard to how the local copy relates to the copy in the org. Technically IntelliJ IDEA does show visual indicators for file status in the local file system and configured VCS, but that's not particularly helpful for the use case you describe.

As you point out, I have added a few things to make this more manageable including conflict detection on deploy (for the multi-user collaborative scenario; I have an open story to address the situation where multiple users are logged in with the same credentials) and metadata retrieval and reconciliation (which is an option when conflicts are detected), but there's not a direct analog to Eclipse's Team Synchronization feature.

When the directory diff is displayed, copying to the left-hand side is an effective no-op right now. I don't examine the contents of that directory for changes and auto-deploy them. You could accomplish the same thing by performing a retrieve, merging retrieved changes into local changes, and then performing a deploy. It's an extra step, and the fact that any attempt to change the left-hand side of the directory comparison is a no-op is potentially confusing, but it should provide similar behavior.

I don't want to lose the ability to use an external diff tool as I find them invaluable for this server/local reconciliation process, but three enhancements do come to mind to improve the usability of this:

1. Make all retrieved files read-only before showing the directory diff to make it clear that copying to the left-hand side isn't valid. This is low-hanging fruit just to keep people
2. Make the retrieve-merge-deploy use case more streamlined, perhaps as a distinct action from just retrieve. Basically initiate a deployment after the directory diff tool has been closed with the assumption that the local project now represents the desired state of the org.
3. As you've requested, add a clear indicator to files that have been updated in the org since they were retrieved or last successfully deployed from the IDE. Hopefully I could do this by extending IntelliJ IDEA's file status indicator mechanism, but it could be expensive in terms of Total API Requests so I would want to be very careful with how it is implemented.

So first let me know if I've interpreted your feedback properly. If not, please let me know where I've misunderstood things. If my interpretation is correct, I'd appreciate additional feedback on whether/how the items above might improve the situation.

Thanks!

[June Bischoff]

I haven't set up a "real" external diff tool yet (other than the TortoiseMerge that we were using prior to our migration to git), which is certainly contributing to my difficulty in that I've got a number of files with differences only in line separators, so my retrieval diff is cluttered with bogus changes, and the occasional false conflict detection. Unfortunately, it doesn't look like TortoiseMerge is compatible with directory-based diffs.

1) I think it would be helpful to make it clear that retrieved files are read-only; I originally assumed that was the case because it was labeled "retrieve", but given the option to copy left in the diff tool I got hopeful.

2) I'm hesitant to automatically deploy the local project after closing the directory diff. What I'm lacking is the ability to clearly tell exactly what changes I'm deploying on a file-by-file basis compared to what's on the org and to have full control over what I do or do not deploy. Automatic deployment of an entire directory based on an assumption of project over org would not move me further in that direction; I might have files with differences that I'm ignoring for now. If I could make the retrieve-or-deploy call on specifically selected files (while looking at the diff), that would be ideal.

3) I think seeing what changed on the org side is overkill, as an ongoing process. I would be happy with an indicator of a file being dirty on the project side compared to last retrieval or successful deployment. I only care about differences with the org on retrieval & deployment.

[Scott Wells]

Okay, that helps quite a bit. I would highly recommend that you take a look at Beyond Compare or Araxis Merge as an external diff tool. The former is my personal preference, but both are very good. Others that work pretty well and are completely free are WinMerge and DiffMerge, but I still think Beyond Compare is worth the small investment. You can easily filter out "uninteresting differences" (primarily white space) and even orphans on one side or the other (useful when you're doing a partial retrieve) to get a very usable diff against the server.

I'll definitely plan to make files on the left-hand side read-only. I'm actually kind of glad to hear that you're not very interested in an auto-deployment-after-retrieve. I do like those as independent operations. I see what you mean about being able to diff in the deployment window, though. I don't think it would be hard to add the ability to allow the user to diff the selected file(s) in the content selection tree. I'll open an enhancement for that as well.

So I think these are the three enhancements we're talking about:

1. Make retrieved metadata read-only before comparison.
2. Add the ability to compare the local file to the server file in the deployment selection dialog.
3. Add a file status indicator showing which files have been modified since being retrieved or last successful deployment, whichever is most recent.

Sound right?

[June Bischoff]

Sounds awesome! The only further enhancement I could envision for 2 would be to have the ability to decide to deploy or retrieve on the fly based on the diff, but as described those three changes will certainly get me going in a workable way.

I also want to reiterate how much I appreciate your rapid responsiveness to all the questions I've had along the way.

[Scott Wells]

My pleasure! This is the kind of feedback that improves the product for everyone.

I'll make this issue the first one (read-only for comparison) and split the other two into their own issues. I'll link them to this one so that you can add yourself as a watcher. I have a few things ahead of these to knock out but should be able to get to them before long.

[Scott Wells]

Added issues #155 and #156 for items 2 and 3 above.

[Scott Wells]

Making this issue represent item 1 above.

[Vivek M. Chawla]

First off, HUGE thanks to @JuneB for her well thought out, well phrased comments. June, you've articulated a lot of my frustrations, and have helped me understand what I think I really want from IC.

Scott, one of the things that I'm really struggling with moving to IC from Eclipse / Force.com IDE is the over-complexity of the retrieve process.

Let's forget for a second about the multiple steps of telling IC what to retrieve and let's assume I've already initiated a metadata fetch. Being forced to go through the diff tool in order to actually get new metadata into my local project is incredibly painful. The diff tool shows so much stuff! It's information overload, especially if I just want to get a copy of what's in the org (the org being the real Source of Truth for code).

There are times when I will want to compare incoming metadata to what's in my project, but for the vast majority of retrieves I don't care if my local files are blown out because I want what's on the server (aka org).

SuggestIon: Could we have TWO options? One would be "Retrieve Metadata", the other would be "Retrieve and Compare Metadata".

The first option would just replace all local files with org metadata. The second option would bring up the diff tool, just like it does right now.

Thanks, Vivek

[Scott Wells]

I just added a comment to #134, but I'll add it here as well to enhance visibility on my thoughts:

I agree totally that a distinct separate notion of Refresh vs. Retrieve is needed where the former is analogous to Refresh from Server and the latter is (more) analogous to Synchronize with Server. I'll sort through the various issues and enhancements around metadata retrieval and figure out which one would best represent this work.

[Vivek M. Chawla]

Hi Scott. Thanks for the reply. Looks like we're all on the same page. :-)

One thing I forgot to mention in my previous comment. I think that @JuneB is spot on with this observation

• I think seeing what changed on the org side is overkill, as an ongoing process. I would be happy with an indicator of a file being dirty on the project side compared to last retrieval or successful deployment. I only care about differences with the org on retrieval & deployment.

I agree with June. Seeing org / local differences on an ongoing basis isn't critical, especially if there was a command that I could execute that would perform the check only when I needed to know if I'm still in sync.

I also agree that your responsiveness to issues and comments is stellar. Thank you very much for the work you're doing!

[Scott Wells]

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

[Scott Wells]

Issue tracker grooming.