Enhanced Backup

Ideas for new features

Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard

Post Reply

How important is this feature for future versions of TextPad?

Important, even if the size/efficiency of TextPad increases/degrades
6
29%
Somewhat important
3
14%
I'm okay either way
3
14%
Somewhat unimportant
5
24%
Unimportant, even if the size/efficiency of TextPad remains unaffected
4
19%
 
Total votes: 21

Jonathan_Taylor
Posts: 5
Joined: Wed Apr 30, 2003 3:02 pm
Location: Halifax, West Yorkshire, England

Enhanced Backup

Post by Jonathan_Taylor »

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.
tygrus78
Posts: 17
Joined: Tue Aug 16, 2005 4:53 am

Post by tygrus78 »

This would be better using a source server (MS SourceSafe) or database or at the filesystem level (Document managment). I think it is out of the scope for TextPad.
justinmo
Posts: 1
Joined: Wed Nov 16, 2005 8:16 am

Fully support this; complexity not necessary at all

Post by justinmo »

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.
justinmo - Adelaide Australia
Post Reply