I have great new idea. And wanna discuss it before implementation.
All who use the application very good know that it not really super stable. And sometimes you save file and only after this understand that it now broken. Not really pleasant experience.
What i propose is the same way experience people do manually. After each saving the make copy of a file and continue work. I propose new option that will allow save 1-1000 last saving in folder near pattern file. A folder will have the same name as pattern file. And will contain pattern files with timestamp. The application will automatically remove “old” savings and create new one. The path to backup folder could be changed in the application options. For example if someone want to have separate place for such backups.
Hello,
it is a very good idea, although I do not see too many crashes.
I use the Mac version, and I can not find too much instability.
However, the implementation of this new feature is the assurance not to take tantrums.
Do you plan to set this function (the number of backup for example)?
If we add the Apple TimeMachine function, then we will be sure to lose nothing.
This sounds like a good idea.
Crashes can occur in various ways, and the crashes are difficult to replicate.
Users have reported losing entire files as a result of the crashes.
This suggestion is a reasonable response to the situation.
I suspect that Barbara’s work with creating the pattern as a tree structure will eliminate some if not all of the crash problem.
Questions:
What advantage does 1000 backup files yield, versus 10 or 100?
Will the ‘auto-save’ setting in Preferences determine frequency of creating backup files?
What advantage does 1000 backup files yield, versus 10 or 100?
The backup folder will contains more your previous steps. Maybe you are right, and 100 is too big number.
2.Will the ‘auto-save’ setting in Preferences determine frequency of creating backup files?
No, ‘auto-save’ setting works only with unsaved changes and if only file was previously changed. No need to make more than one file.
The application will create backup copy only after user will click on save button. This way he shows us he want this state to be saved. The feature allow him to do it more frequently without fear of loosing data. And bothering about manual making backup copies.
Again, the main reason for this feature is losing data of pattern after saving broken pattern into file. With this feature user will have enough save points to restore his data and continue work.
Just to add my 5c worth I find the autosave feature very reliable. I’m working on Windows 10 and have very unreliable electricity. It has been a few times that my computer has cut out on me in the middle of doing something and when I get back, I can choose to carry on where I left off or not to. The 1st time I chose to carry on where I left off, I was pleasantly surprised to find that I hadn’t lost any information at all.
I have my basic pattern block and when I create something else from it, I always first save it into its pattern folder under a name that I can identify with before making changes to my basic pattern. And I copy my folder over to an external drive at least weekly as a further backup. For people working professionally, I’d suggest daily.
I disagree with this. One reason for this is that on more than 1 occasion a user has caused a pattern to crash - such as changing a point name - and the “single” backup file is messed up as well. By having versioned (multiple) backups, there’s a good chance that you can go back to a point where the pattern is not messed up to recover the pattern up to the point where it got messed up. While there are some of us that can fix munged pattern XML files, it’s absurd to expect your average user to do so. They should be able to select a backup that works. Plus, there are times where maybe one wants to delete items back to a certain point… having versioned backups allows for this. The number of saved backups would be another preference along with the time between backups. Also… the naming convention of backup files should be addressed as well… as you may note in the image below, the file extension remains the same.
The ability to save versioned backups is a common feature used in video editors and audio DAW’s where it’s critical not to loose one’s work. It should be noted that in Presonus Studio One, the song “backups” are placed in a “History” folder, while the active song file is saved in the parent directory. Under normal circumstances you never have to see the backups unless you open the folder. This keeps the parent directory clean.
That would be a wonderful feature. In my accounting program, it saves the file with its name, date, hour, minute, second - not a number, as such. So if one backs up often, then one can go back to the previous one or the one previous to that one very easily by checking the date and exact time of the backup in relation to other backups.
Aha… that’s what the numbers in Presonus autosave files are doing. If you look at the Date Modified you can see the date&time… which corresponds to the files name… 20210802-122031 is Aug 2, 2021 12:20:31. Maybe this could / should a pref based on a users locale for date&time? Presonus is a British Company thus the yy//mm/dd - which I have a hard time reading as we use mm/dd/yy in the States.
I kinda of like the idea too that it notes it’s an “Autosaved” file. I’d have to go back and read again the short discussion Susan & I had on Github in regards to the (re)naming of a pattern file when it get’s converted, but as I recall part of the thing we didn’t like was the .bak extension. Not only is it unnecessary, it render the file useless until the name is changed back to a .val. While not specifically a backup file, the (re)naming convention also needs work. Figured I could kill 2 birds with one stone here.
The benefit of YYYY/MM/DD is that when sorting files by alphabetical order they are placed in the dating order. With mm/dd/yy the backup on New Years Eve comes after the backup on New Years Day. & it doesn’t sound like the backups should be automatically deprecated rarely enough for that not to cause problems.
Hola,
Me parece una idea excelente, precisamente estaba pensando en comentarlo, ahora que estoy revisando las nuevas opciones y me ha pasado varias veces que el programa se cierra de pronto y eso que intento ir grabando cada momento. Lo que no entiendo es que a veces cuando quieres grabar el archivo solo puedes usar : grabar como, porque la otra opción no esta activa.
No se si puede servir como ejemplo pero el programa Inkscape que yo uso y que pasa a veces lo mismo crea una copia de seguridad, en el nombre añade la fecha y otros datos más. También se podría ir grabando automáticamente en menos tiempo y si colapsa crear un archivo de seguridad.
Un saludo,
Pilar
Hola Douglas,
En mi caso se me colapsa no acabo de saber que hago para que sea así, aunque estoy pendiente de ir grabando a menudo, me he quedado sin algunas ultimas modificaciones. A lo mejor cambiando el intervalo de autoguardado a menos de 1 minuto ayudaría a tener los cambios más actualizados antes de que se colapse.
De todas formas agradeceros a todos vuestro trabajo, me encantan los cambios que habéis hecho, aunque voy poco a poco porque sigo siendo una novata con Seamly.
No acabo de entender que hay que hacer con las actualizaciones semanales para Windows de las que habláis
Well I looked at some of the code for auto saving a pattern file… not surprisingly the code suffers from the usual incorrect usage of English terminology.
So… not only is the “.autosave” string NOT a prefix… it’s NOT a suffix either. It’s an extension.
At any rate… there is an easy fix to allow multiple autosave files. Currently the app takes the current open file and looks if there is a current filename + .“autosave” - if so it gets removed. Then a new file is saved as current filename + ."autosave. By adding a preference check box item say “Allow versioned auto saves” , in the AutoSavePattern() method we would check If (ui->versionedAutoSave) then we would just save a new file with the filename format [name][date] [time] + “(autosave)” .val else perform the current remove filename & save new filename using the same format above.
So… what I suggest is that an autofile name format should use the date & time formats set in the prefs - formated in a filename acceptable format for example mm/dd/yyyy doesn’t work… would have to be something like mm-dd-yyyy, mm_dd_yyyy, or simply mmddyyyy.
the date & time would be followed by “(autosave)” followed by the “.val” extension.
I would store the autosave’s in a “history” sub folder.
Something else I though of, and not sure what the normal practice is, another one of those code related translation issue… should the “(autosave)” be a traanslated string? Easy enough to do by wrapping the text string in tr().
Makes sense if not being used as a file extension… which as I’ve already noted I don’t agree with using autosave as a file extension. Not to mention that while there’s no longer a limit to the number of chars for an extension, going past 3-4 chars breaks with convention. Makes sense to stick with the same file extension so the associations stay the same.
Not to go way off topic, at some point it would behoove us to change the file extension to make that final break from Valentina. Thing is its next to impossible to come up with unique extensions. For ex: .S2D and .SME which would make sense are both in use elsewhere.
And wanna discuss it before implementation.
