Agree with Ingo. Especially as we have no indicator when a save takes place, it creates uncertainty what happens in the back.   On U9, the developer has the control what is saved or canceled (ok "compile" has an implicit store) So when a colleague walked by after some 2 hrs of modifying the code and told me that this will endanger the application, a simple QUIT is all it takes to clear the situation. In U9, I had an ADDITIONAL menu with some "timestamped export of current object" item. So if the test unveils some strange sideeffects, there was always a simple "import last green export".   Walkback in U10 seems not that easy.

I see your point and we are aware of it. So, why the ... did we do it like this? There are number of things going on here. The most important reasons for this implicit save is a technical one. All views/editors of the IDE communicate of the repository; there is no data kept in memory, because the amount of data that the IDE can show simultaneously can be huge. Think of a lot of open editors and they all show a lot of inherited properties. All this data should be loaded into memory, being maintained in memory, and being rolled out to all open views/editors from memory. Note that Uniface 9 does not suffer from this problem, because it only shows 1 editor at a time. So it is less of a problem to keep data in memory for a longer period of time. So, as a starting, we started of using this architecture. But, obviously I see your point of not having enough recovery points and these will be handled; its all part of the bigger plan:

• The idea is to have undo/redo for all data, so not only for code, but also for object creation, deletion, and property updates. This at least allows you to always go back to a previous state.
• Additionally, we want to have a perfect version control integration meaning there will be a file-based Work Area integration. That Work Area will be the place where you will maintain your sources and where version control integration takes place. And than the version control is the place where you maintain different versions of of you work. A tool like Git is perfect for this, even if you only use to manage local versions of your work. The repository becomes more and more an 'internal' index on the sources.
• However, for you shared repository folk, we might introduce a recovery point mechanism. This will be based on the undo/redo mechanism and allows you to go back to any moment you defined; almost the same as not storing you saves.

So, we are not there yet. But we will get there. Gerton