Refresh/retrieve in one operation

[Derek Wiers]

One thing I never understood was why Refresh and Retrieve are 2 separate operations in IC/IJ. Is there any way to combine these so that you don't have to run both separately when you want to update all your local data?

[Scott Wells]

Derek, here's an explanation of Refresh vs. Retrieve and within Retrieve, Retrieve vs. Retrieve for Merge:

https://groups.google.com/a/illuminatedcloud.com/forum/?utm_medium=email&utm_source=footer#!msg/qanda/MO4QwTj5Kz8/fNx8S5MVAwAJ

Now, having said all that, the fact that both exist is more evolutionary than by original design. It's possible that with the recent parallelization work I did enumerating metadata these two could be merged, though some people have definitely said that they like having an option to pull from the server without any intermediate dialogs.

Anyway, take a look at that linked info and let me know your thoughts...

[Derek Wiers]

Hmm. Perhaps have a third option, like "Refresh All" or something, that allows for a one-click retrieve operation, similar to other IDEs (perhaps with an optional merge functionality similar to retrieve)? Especially for 1.x, it could probably just be the concatenation of the two existing processes to save coding effort, and then maybe optimized in 2.x to make it faster (since I have no doubt that the two separate existing processes could be combined more time-efficiently than calling one after another). Sorry, I'm getting into implementation detail here, but those be my thoughts.

[Scott Wells]

I'll definitely keep this open and chew on it. I don't think I want to add a third operation since the existing 2/3 already cause enough confusion. I think I'd like to go the other direction and simplify it while trying to achieve a good performance/simplicity trade-off. The SFDX pull/push model is very nice, but it lacks selective/partial pull/push and the ability to review/merge retrieved metadata. I think a hybrid of the two would solve most of this, but I need to make sure I can do it without adding the overhead of full metadata enumeration in all cases. The recent performance optimization definitely helps there, but some folks work in orgs with a TON of metadata and/or with long process build flow version histories that makes that enumeration a long process even with the optimization.

I'll keep chewing on it and hopefully I can come up with something that will work well...

[Scott Wells]

I believe this should be largely obviated by many of the enhancements around metadata retrieval, specifically those included in 2.2.9.2.