It probably doesn't do what you think it does.

I, at least, thought it saved your document and made a numbered copy (~000, ~001, ...), the two saved documents being the same and representing a snapshot of my work at the time the backup was made.

What I believe it actually does is the following:

If you have never saved the document, it asks for a name and saves it under that name. There is no backup made. If you have previously saved the document, it saves the current state and makes a backup which is the state the document was in when you last saved it, not now.

I determined these facts after doing this experiment:

1. Created a new document. Drew a big A in it, then did F4 (shortcut for Save Incremental Backup on the File menu.)
I then had one document (i.e there was no backup created.) The document had an A in it.
[On Windows it is easy to tell what is in the files without opening them if you use View|Large icons in File Explorer.]
2. Erased the A and drew a B. Did F4.
I then had the document and one backup with the name containing ~000.
The document had B (current state of the document), and 000 had A. (not the current state of the document).
3. Erased the B and drew a C. Did F4.
I then had the document with C, 001 with B, and 000 with A.
4. Erased the C and drew a D. Did F4.
I then had the document with D, 002 with C, 001 with B, and 000 with A.
5. To see what would happen, I erased the D and drew an E, then did Ctrl-S (plain Save).
I then had the document with E, 002 with C, 001 with B, and 000 with A.
6. I then did F4.
I then had the document with E, 003 with E, 002 with C, 001 with B, and 000 with A.
At this point the document and the latest backup are the same and represent the current state of the document (what I wanted).

I had previously noticed that the file modification times on the backups were not what I expected (they were in the past), and recently that the backup actually did not contain the state of the document when it was saved.

I submitted both as a bug at the time they happened to me. (#401795 and # 404782) The first is marked as NOT A BUG, and the second is marked as WORKSFORME. The rationale for the latter was listed as "We've had this functionality like this since 2013...".

The documentation now states: Backup the original file you loaded, then save your image under the original filename.

I have no ideas what it means by "Backup the original file you loaded", but in reality my experiments tell me it makes a backup that is what was in the document the previous time you saved it (or no backup if not previously saved.)

I can think of no rational reason for doing it this way, and lots of downsides, e.g., when you go to use it, you will find its contents are not what was in the document when you did the backup, meaning it probably doesn't have some of the changes you made.

I personally think it is broken and should be fixed, but I have no control of what the developers think or do. I try not to be critical online, but this bothers me. It isn't right.

In the meantime be aware of what it is really doing. Note that if you do a plain save first, then do the incremental backup, the document and the backup will have the same contents and they will both have the state of the document at the time you made the backup (what i, at least, want.)

That you have to do two steps and wait for an extra file save is the price you have to pay to have the backup be the current state of the document.

It might be that I just wrote it down wrong in the manual, you know. I am human too...

EDIT: Changed it to 'Copies and renames the last saved version of your file to a back-up file and saves your document under the original name.', which is what I observe here.

It sounds like you want to use "Save incremental version" instead of "Save incremental backup"?

TheraHedwig wrote:EDIT: Changed it to 'Copies and renames the last saved version of your file to a back-up file and saves your document under the original name.', which is what I observe here.

Heh, I thought I had sufficiently clarified that from the original already.

In any case, there's nothing to "beware of". Things are perfectly clear and logical:

save: save the current state to the current filename, overwriting it and optionally leaving a backup file of the original file. In Master, you can have 0..10 versions backup files referring to older versions _as they were saved_.

save as: save the current state to a new filename. Next time you save, it will save under that filename again.

export: save the current state to a new filename. Next time you save, it will save under the old filename.

save incremental version: save to a new filename, with an incremented version number.

save incremental backup: save to the original filename, but first copy the original file to a new filename with an incremented version number.

What kenneth wants is "save to the original filename and save also to a new filename with an incremented version number". Well, that's not what we have, and I think adding it will only serve to confuse people.

Edit: there's also this: https://github.com/abeimler/krita-plugin-durra

I don't use incremental backups to understand what you are talking about, but there are also some additional options coming to Krita 4.2 that allow you to customize the way incremental backups work.

https://krita.org/wp-content/uploads/20 ... ptions.png

You can also test these out early in the "Krita Next" build you can find on the download page. I am not sure if other fixes were done beyond adding these configuration options

@kenneth: "Save incremental backup" works fine. What you want is "save incremental version"
To understand "Save incremental backup", imagine to be editing a texture.png file linked to a 3D scene.
You need to keep the same filename: texture.png; or you'll break the link between your 3D and your texture.
If you save; it will overwrites: you'll loose the previous version. That can be problematic if a art-director tells you "I prefered the previous version" especially for artist not running a CVS. With "Save incremental backup", you save (overwrite) and Krita put a 'backup' (the previous version) on the side... It is then easier to find a previous version and revert a issue. That should bring light to your confusion. Maybe you couldn't understand the feature because of how it is named or worded? but the feature itself does what it is supposed to do for a very common workflow. How you would name that behavior?

Hey,

judging from your post and your bug reports, you seem to not understand fully what the feature is about and why it is implemented the way it is. Maybe the manual is unclear in this point; if so, please suggest a way to improve it (or even improve it yourself! The Manual is written mostly by volunteers).

You probably already know what happens when you save a file: if there is a file with the same name already in the folder, the old file is being copied to file called [filename]~ (it's called "a backup file"), and the current state of the image opened in Krita is saved as [filename]. If the backup file already exists, it's being removed. This mechanism is implemented to make sure that if the saving of the file fails (i.e. power goes off and your computer turns off itself in the middle of saving), you at least have the previous version.

Incremental backup works mostly the same way, the only difference is that instead of saving to [filename]~, it saves to [filename]~000, [filename]~001,[filename]~002 and so on, incrementing the number in the backup file name every time. This feature was asked by David Revoy, who is an artist who works closely with Krita developers. (I wrote this before David posted his comment, but now you can see what this feature is for).

Your bug reports were closed, because the issue was investigated and no difference between intent and the actual functionality has been found. If you don't like the way this feature works, you can freely propose a different solution; you just need to follow the guidance of feature requests instead of bug reporting. When you make a feature request, you need to (1) say what exactly you want, (2) what workflow this feature will be helpful with, and (3) why all other solution existing now in the software are not working for you. So, basically, you need to tell us not only *what* you want, but *why* you want it; how would it help you and so on.

Hopefully that explained some things

Wow, I lot happened while I was gone. I thank all of you for your interest. I will try to respond to all of you.

First, the manual now says what it does pretty clearly and accurately. Thanks for changing it. It could also say there will be no backup created the first time, but I'm ok with it as is (as far a being an accurate statement of what it does).

@boudewijn I disagree with you that there's nothing to "beware of" and especially that things are perfectly clear and logical. I am not stupid, and it certainly got me. At the time it was definitely not clear, but I think, as said, it is now clearly stating what it does. I'm sorry but I do not consider it logical. The main reason is that you are making a backup, not of the current state, but of some state in the past. Why would I as a user, not necessarily used to what it does from having used it for a long time, expect that. It's crazy. If I make a backup, I want a backup of what I'm doing, not something I did in the past. I can't believe that's not what most people (non-cognicenti) would want.

@tymond Yes, I did not understand fully the feature. That is both because it is not intuitive (I expect a backup to be of what I am doing now) and because it was not well documented. The latter has been corrected, and at this time I do understand the feature in depth. I could consider making a feature request, but I think you will agree that if we don't reach an agreement here, that it would be a waste of my time. The major players seem to be involved in this discussion. Consider that I represent the user, not the developer. You don't seem to have been getting that input.

@scott petrovic. I looked at the new features. They don't fix the issue of whether backups should be of the current state or a past state. But thanks.

@Deevad First I acknowledge that you are a better artist than I will ever be, a more frequent user of Krita, and a person who has made many more contributions to Krita than I ever will. So I treat what you say with considerable respect. I agree I want incremental backups. (I don't want the name to change.) I don't how doing it my way violates any of the features you say are necessary. My way, I save whenever I am at a saving point that an art director might want to go back to. I know exactly what is in the backup, and the modified date will be correct date for when I made that backup. I can go back to any point the art director wants. What am I missing?

Both ways leave a chain of backups, which is good in itself. It seems to me that my way the backups are what they should be rather than one save version behind. The save thing especially doesn't work with my workflow. From many years of using many programs, I follow the "Backup early, and backup often" philosophy. As a result I backup whenever I happen to think of it, not when I'm at a point an art directory (that would be me) might find useful. The current way leaves me with backups made at meaningless times.

To summarize, the key feature to me is that the backup be of the state at the time I make it. This is what is intuitive and what I think most users would expect. I don't see how doing it this way interferes with any requirements professional artists with art directors (or anyone else) would have. You all seem used to doing it the current way. Think about what I am saying. To convince me you would have to show why your way is more intuitive (i.e.easier for most users) or that my way leaves requirements unfulfilled.

Thanks for your time.

It seems like Kenneth Evans has a point (kinda) about the "meaningless dates". Well if you trust Windows with dates, that's what you get

Here is a comparison of dates in different incremental save methods:

https://i.imgur.com/u3K7cEN.png

Basically every backup file has reverse dates on modification and creation, which makes sense (let's analyse the incback-save.kra and its backup; the main file was created on time A and modified on time B, when the backup file was created - so the backup file has the creation date B and modification date A, since it's a backup of previous state). Unfortunately Windows has three categories in the file browser for dates: "Creation date" and "Modification date" when you ask for it, and the default "Date" which just takes both dates ("creation" and "modification") and selects the earlier one. Hence confusion.

Just use "Modification date" (add it to the file browser window when you look at the "Detailed" view and then sort) and you'll be fine; the order is correct that way. The last "backup" file is just the main file, so if you want to show it to art director and need all stages to be numbered, just duplicate and rename the main file to [main file name]~00[last backup number + 1].kra. It will give you the same results you expect from "your way".

Also, please try the "Create incremental version" feature. It doesn't mess with dates and looks like something you would like more.

@tymond I don't think you understand my point. Yes, the dates are in the past because the backup is from the past. They are consistent. The point is that in any other program I can think of (and this includes version control) when you make a backup, it is of the current state of the document. It is not the state at some time in the past as it is with the current Krita scheme.

Imagine if Git worked that way.

In my case, since I save frequently, much more frequently than I want labeled backups, this ends up being at a time that is not even meaningful to me.

In addition, there is NO backup of my current work. If something bad happens, that is LOST. This alone should be reason to drop the current scheme: it doesn't backup your current work.

(Yes, there is the saved version. That however is gone when I do the next Save. I've then lost ANY backup of the time I wanted it -- the time when it was appropriate to make a backup -- the time the art director would want it.)

And don't bring up the ~ backups. They were not working for some time. (Another bug I submitted. I don't recall if it's fixed or not.) In my mind those are a last resort.

Why don't I get a backup of my work at the time I choose to make a backup? That is the part that just doesn't make sense to me. It would be just as easy to do it so that happens, and I can't see any downsides other than a change would have to be made. (Also you would get the first backup, which doesn't happen currently.)

I've waited several days. It looks as if there is going to be no response to my points.

Galileo once said the simple reasoning of a single individual is worth more than the unstudied opinion of a multitude.

This is the simple reasoning:

The Krita incremental backup scheme gives you a backup of something you did in the past. The major problem is that it does NOT give you a backup of your current work.

If this is ok with you, you're good to go.

If you would like to backup your current work rather than something from the past, then do a Save followed by the Incremental Backup.

it seems that the answer has been given to you several time. for the workflow you want, you have to use "save incremental version" not save incremental backup. I don't understand what is the issue for you?

mcoudert wrote:it seems that the answer has been given to you several time. for the workflow you want, you have to use "save incremental version" not save incremental backup. I don't understand what is the issue for you?

I don't want the name of the file I am working on to change. I believe @deevad said the same thing.

Then use "File > Export..." when you want to make a backup, so you will have a backup and you're continuing to work on the "root" file.

Thank you for your solution and to all the others with workarounds for this issue. After extensive thought, I have personally chosen to work around it by using another art program. It is not owing to the issue itself, which is easily handled once it is understood. It is rather the way in which the issue (and at least one other like it) has been handled. I am used to an environment in which open discussion is more valued, and minds are more open. I don't need this in my life. I find it unpleasant, and it has caused me to lose any desire I may once have had to help make Krita be a better program. In the words of a Kris Khristofferson song, "I ain't getting out of here no more faster than I can." I do not expect to be missed.