At the moment, TextPad can be configured to store a backup of a file after every save.
However, there is only one copy of the backup file, which is overwritten after every save.
It would be nice if it was possible to backup EVERY save of a file, allowing the file to revert to a backup from any point in time.
I know this could result in the use of HUGE disk storage over time, but here are some suggestions to alleviate this problem.
- Limit the size of the backup directory (for all files). More recent backups would overwrite older backups if this threshold was reached.
- Limit the number/size of backups for each individual file.
- Use the SCCS (and other source control systems) method of only storing DIFFERENCES between versions.
This type of backup could be turned on for individual files, or even for a document class (i.e. program source code).
I can forsee performance problems with very large files, therefore this option could be disallowed for large files.
Enhanced Backup
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
-
- Posts: 5
- Joined: Wed Apr 30, 2003 3:02 pm
- Location: Halifax, West Yorkshire, England
Fully support this; complexity not necessary at all
This is an improvement I would value highly, it makes the program work better for authors writing stuff themselves.
It does not need any computational complexity at all; all it needs is for one more option to be added to the backup file options so that instead of having only "filename.bak" or "filename.ext" it could also have "filename_timeanddate.ext" with time and date entered just as yyyymmddhhmmss numbers preferably.
These are text files, in most contexts of modern storage their space occupation is notional at most; and those who deal with 10Mb files would have their own coping capacities anyway, and it can always be configured as an opt in option, off by default.
Very important; please do this.
It does not need any computational complexity at all; all it needs is for one more option to be added to the backup file options so that instead of having only "filename.bak" or "filename.ext" it could also have "filename_timeanddate.ext" with time and date entered just as yyyymmddhhmmss numbers preferably.
These are text files, in most contexts of modern storage their space occupation is notional at most; and those who deal with 10Mb files would have their own coping capacities anyway, and it can always be configured as an opt in option, off by default.
Very important; please do this.
justinmo - Adelaide Australia