I think as long as the situations where a file can be corrupted are solved, this could remain as an experimental feature that can provoque crashes, but it can be enabled by the user.
The only thing that would stop me from enabling it would be the files thing, @mont29 can you specify a bit more in what situations we can observe such corruption?
Am not aware currently of any actual case leading to file corruption (typically crash will happen before you have an opportunity to save a corrupted file), but we are doing black magic with memory addresses in that work, so itās very hard to fully rule out that possibilityā¦
Ok, so a good safe guard could be to have several blend1, blend2, blend3 ā¦ also, how could you detect a corrupted file? only when you open it after it has been closed? (in case it does not crash)
@mont29 Have you tested uuid-undo-experiments-swap-reread-datablocks with undoing selections? My build on Windows just immediately crashes if I click select a few things in the default scene to load up an Undo stack and then hit Ctrl-Z. Iām not sure what the difference is but Iāve tried both builds with just āmakeā and āmake releaseā. Still trying to figure out how to get a decent stack trace.
edit: Well, it seems Ctrl-Z crashes for anything on me.
Cannot reproduce hereā¦ Could be OS-specific though (would not be the first time windows crashes when linux works fine, even in ASAN debug builds 
)
I can repro the undo crash after select changes as of ad88b84c5df on that branch.
**id_old** was nullptr.
blender.exe!read_libblock(FileData * fd, Main * main, BHead * bhead, const int tag, const bool placeholder_set_indirect_extern, ID * * r_id) Line 9226 C
id_old->recalc = id_old->recalc_undo_accumulated;
EDIT: Of course a few minutes later efee90959fa fixed things up 
No immediately obvious crash after trying some things out.
EDIT 2: For folks coming in now, remember to actually ENABLE the new code by going to Preferences ā Experimental
Are you guys doing custom builds for this or is there a build somewhere? Was looking at the experimental builds, canāt really see anything on blender.org, for linux at least.
Iām just doing custom windows builds locally. Thereās no official build for this particular branch for linux or otherwise. If so, it would show up here: https://builder.blender.org/download/branches/
Ye, was wondering about that, wasnāt sure if itās in the experimental build there. Thanks for clarifying.
Me too, custom build from the test branch
I tried the undo feature by enabling it in the latest build, and trying to figure out what scenarios itād be useful in itās current state.
Didnāt have noticeable speedup sadly, with the feature enabled vs disabled. I have a scene with 1* 40M poly object and a simple 6 poly cube. Undoing simple translations for either of them is still painfully slow compared to any other packages.
Is this supposed to make a difference for scenes with many low/midpoly (1000+) objects only?
Thatās weird, you saw my video right?
Are you sure you enabled it in experimental? Becaus for me it worked perfectly fine
I saw the video, but I also tried the latest master build with the experimental feature enabled, under both linux, windows 10 and macOS.
No Speedup whatsoever with one 40M object, simple translate undo; one 40M object and one 6 poly cube, simple translate undo; or 2000 * 3000 poly objects, simple translate undo.
Out of curiosity, did you try it with a single high poly object (20M+ poly) for just undoing simple translates?
I did a quick test, I will publish a video about it, but the results are these:
1.- Master branch Undo Speedup: no difference, the undo speed is the same with or without the Undo Speedup enabled, nothing changes
2.- uuid-undo-experiments-swap-reread-datablocks: the undo is between 3 to 4 times faster
@mont29 is this behaviour expectected? is something not commited yet in master to make the undo speedup work?
Thank you for doing the test Juan! Appreciate it. It seems some major multires work is depending in this as well, itād be good to know the state if this. Donāt mind if it takes time of course as itās a tricky problem, itād be good to know about some kind of rough roadmap though.
Also, for the record - faster is one thing, but comparison to any other major package should be the overall guideline, be it for the first undo step (which is the only one being used in 90% of cases) or any other scenario. Most times people only undoing simple things like selection, translate or assigning a material. If thatās not instant itās kinda hard to sell a package to professionals these days.
Just checked, itās working as expected here for me, both with latest nightly builds and own build of masterā¦
That kind of very interesting. I loaded the latest build today.
blender-2.83-42012493a8e1-windows64
As soon as i duplicate an object the fast undo doesnāt work anymore
It would be nice if changes were trackable in Undo history list. I mean:
currently if I change a single value e.g. Sampling > Render from 50 to 100, then in the undo history list this is shown as just ā100ā. Yes just the number. A very useful output would something like:
So: context, new value and (old value)
This way, without performing any Undo action, the user could revert some values from history.
All this UI improvements are good.
But, guys, undo is kinda common feature witch should not be THAT kind of problem. It is literally impossible to work with a big scenes.
doing various tests, with the last build the old demo files no longer crash (some continue to crash, such as the classroom) if the experimental undo is activated, but the undo continues to be slow,
for example loading the demo file the wanderer which has heavy meshes, by moving objects in object mode and then doing undo, it continues to be slow, I donāt know if it is due to heavy objects or some other reason