@bkarabinchak.psi yes, that is all correct.
1 Like
Perfect!
Just stumbling across this thread after years of being somewhat confused about the seemingly inconsistent/easy-to-screw-up save/revert (and even "publish" in 8.0 beta - please bring that back!) functionalities. I'm surprised there's not mention of the two different Close & Revert behaviors vs the Revert Changes option, nor that clicking "no" on "would you like to commit" dialog doesn't always revert the resource to it's pristine state.
- open perspective project.
- open a single view
a. observe that the view's name is not italicized (in the tree)
b. observe the context menu does not containRevert Changes
c. observe selectingClose & Revertappears to properly "revert" the view (though no changes were made) - open multiple views
a. observe all previously-opened but unmodified view names (except for the last) now are italicized (in the tree, despite no changes made)
b. observe all previously-opened but unmodified view context menus now do containRevert Changes
c. observe selecting any previously-opened but unmodified view'sClose & Revertdoes not "revert" the view (they remain italicized in the tree)
d. observe any previously-opened view'sRevert Changesdoes "revert" the view
I (think) I eventually figured out the rationale for this behavior, but only after shooting myself in the foot a few hundred times before finding out about CTRL+SHIFT+S - as Carl said above, Perspective apparently automatically italicizes/commits when a resource is closed, but it also appears to do so when any other resource is opened. Unfortunately this behavior blurs the line between Close & Revert (last opened or updated) and Revert Changes (last sav[ed] or load[ed]) - even if zero modifications have made. The confirmation dialog for the latter isn't exaclty more clear either.
In my multi-developer experience (many who have probably previously been not-inaccurately advised to save early and often, but who don't all know about CTRL+SHIFT+S), we're constantly fighting the ramifications of unintentional full-saves (usually innocent changes like client tags/session props/property bindings as a result of previewing/navigating in the designer while troubleshooting/investigating). Of course even the smallest tweak can wreak havoc on vision change merges. Sure, we have DEV/QA/Test/Prod environment(s), source control where feasible, and make thorough use of initialization functions to sanitize things when opened in runtime, but we can still royally bork the DEV environment or accidentally merge unintentional changes to QA/PROD if we're not careful (can't realistically do usefully diff-able source control in Vision)
I do realize I may be incorrectly conflating committed vs italicized resource names, and I likely thoroughly underestimate the effort needed (and the edge cases that must be considered) around this functionality.