Save undo stack

[adforum]

Hi.

 

A huge feature to have would be undo stack to be saved to affinity files. That way, we could work on projects as if we never left them.

Additionally in fact, a full versionning system could be great, but if we also could

- name some steps so that we can go back and forth in our edit history

- freeze edits below a certain point (but still see what it looked like and copy elements from those steps)

- export at some points in 'time'

- have time and date for each edit

 

This is to be able to cope with customers that cannot take decisions and be able to always get back on previous edits to show what it looked like at that moment. You could say that i should save each and every results, but you never know in advance what you will need and that is 1: a huge disk and time loss to organise it and 2: not an absolute way of ensuring that you always be able to sort things out. You cannot save everything manually.

[ronnyb]

I've had the same idea before, and I think it could be super useful in certain phases of the design process. A check-mark in the Save dialog box giving users the choice to save their History (as defined by the number of Undos in the Preferences, would be a simple and effective v1.0 of this feature... I can't imagine file size not swelling exponentially, but really, what are all those cheap and empty gigabytes for?

[Dave Harris]

We actually already save the undo history in autosaved files. We don't for normal saves mainly because of a lack of nerve. The danger comes when loading a document from an older version of Affinity into a newer version. If commands have changed, we have to ensure the new version of it can load the old version's data. We have a lot of commands, that evolve over time, and this would be a constant coding and testing burden for the future. I think we will add the checkbox eventually; we just have to find the courage to commit to supporting it.

 

The other suggestions are interesting. I believe AndyS has been working on a feature in that area that might help.

[adforum]

Hello.

 

On the compatibility thing, maybe one thing to do could be a first iteration where edits are lost on version change. People could still keep the file but would only be able to see the edits at an eventual later time, once you commit to translate old revisions to a new one. (if you ever do. I'm a long time coder too and i totally understand your argument)

I do not see removing of edits as a problem on the long term anyway. It is pretty useful during the life of the project, to be able to go back and forth. Once the project itself is done and customer has its product delivered, there is little reason to need such a feature.

 

Saving steps would help most of us, i believe, just by the fact of feeling as if we never left the project and the confidence of being able to go back on last steps.. (don't most of thought "i really did sh*t tonight..." when waking up after a tiring night session?)

Being able to get back on projects made months or years ago would only be needed for a few of us.

All this is IMHO, of course. 

 

Oh, and on the marketing side, it's a nice feature to brag about. ;)

[Ben]

From working in the games industry, this "problem" was largely solved for art assets by Version Control, such as Perforce.  It is much more granular than saving an entire undo stack, and dependant on the user choosing to commit revisions, but the result is the same.  Version control systems usually offer ways for getting back to earlier revisions.

 

For the most part, our undo stack will create a modest amount of data unless you are doing a lot of raster/bitmap work.  If we always serialised these commands, files would get very big very quickly due to raster content.  As Dave says, we do this for autosave files already, so we have the ability to do it.  The difference is, autosave files are separate to your main document file and aren't visible to iCloud or other apps, so other issues are avoided. iCloud, for example, will update your file to cloud if it detects changes.  Without saving the undo stack, the atomic changes to most files will be relatively small, even for raster heavy documents, and so iCloud updates should be relatively quick.  We do a few tricks in the file format to try minimise overall changes to the file to help improve this.