keep a number of file backups #548

Open
timblechmann opened this Issue Sep 27, 2012 · 13 comments

Projects

None yet

9 participants

@timblechmann

when storing a file, we should keep a number of backups of the file to avoid data loss when accidentally saving a file.
files could have an additional extension like .1.

@danstowell
Member

should we? I wouldn't like that clutter, personally. vote for off-by-default

2012/9/27 Tim Blechmann notifications@github.com

when storing a file, we should keep a number of backups of the file to
avoid data loss when accidentally saving a file.
files could have an additional extension like .1.


Reply to this email directly or view it on GitHubhttps://github.com/supercollider/supercollider/issues/548.

http://www.mcld.co.uk

@timblechmann

this is one of the features, you won't miss before you accidentally overwrote your last piece without having a backup.

we could place them to Platform.userAppSupportDir +/+ "scide_backups", though.

@telephon
Member

On 28.09.2012, at 10:24, Tim Blechmann notifications@github.com wrote:

this is one of the features, you won't miss before you accidentally overwrote your last piece without having a backup.

we could place them to `Platform.userAppSupportDir +/+ "scide_backups", though.

This is usually taken care for by the operating system, no?

@timblechmann

no

@telephon
Member

On 28.09.2012, at 10:49, Tim Blechmann notifications@github.com wrote:

no

well, ok then ...

@sensestage

On Friday 28 September 2012 10:24:37 Tim Blechmann wrote:

this is one of the features, you won't miss before you accidentally
overwrote your last piece without having a backup.

we could place them to `Platform.userAppSupportDir +/+ "scide_backups",
though.

this is what I use git for...

some backups are useful, but they shouldn't grow too numerous.
Emacs has this nice feature that it informs you when there is a temporary file
for the file you open, (in case emacs crashed), and suggests to recover that
file. Maybe that could be the mechanism to ensure that the backup files are
not cluttering too much?

Not sure whether putting them in the support dir is the best thing to do.. you
may loose track of them; if they are next to the file that it backs up, at
least you know it's there, and when you copy the folder, you will still have
it with you; nothing so irritating as having the backup on the machine you
left at home when you need it.

sincerely,
Marije

@muellmusik
Collaborator

I believe OSX does do it, but I don't know if something needs to be done to enable it in Qt based apps.

On 28 Sep 2012, at 09:55, Julian Rohrhuber wrote:

On 28.09.2012, at 10:49, Tim Blechmann notifications@github.com wrote:

no

well, ok then ...

Reply to this email directly or view it on GitHub.

@timblechmann

this is one of the features, you won't miss before you accidentally
overwrote your last piece without having a backup.

we could place them to `Platform.userAppSupportDir +/+ "scide_backups",
though.

this is what I use git for...

usually you save more often than you do git commits ... any many of our
users seem to have problems with running version control systems.
it is actually a standard editor feature which can also be found in
gedit, kate (usually named 'backup on save').

some backups are useful, but they shouldn't grow too numerous.
Emacs has this nice feature that it informs you when there is a temporary file
for the file you open, (in case emacs crashed), and suggests to recover that
file. Maybe that could be the mechanism to ensure that the backup files are
not cluttering too much?

autosave is a separate issue. iirc, emacs does an autosave after a few
hundred key strokes, gedit can be configured to auto-save every few
minutes. kate and emacs save a temp file with the current state of the
file while editing, so in case of a crash, one can recover the current
state of the file.

@joshpar
Member
joshpar commented Sep 28, 2012

Actually, I have a Document based Backup class that I used with the Cocoa SC.app. I added it to my startup file and it backed things up every 3 minutes every doc that had changed. I also give it to students to use, and I can't tell you how many times it has saved numerous people. Yeah, I have a folder with 200 some files on my computer, but I sure am glad they are there when I need it, and I don't see it unless I am looking for it. Off / On by default, I don't care, but this functionality would be RAD RAD RAD.

@jamshark70
Collaborator

FWIW, I would rather have this as a feature that users could turn off if they already, than not have it at all because some users don't like it.

I would use such a feature, definitely.

@jamshark70
Collaborator

"If they wish"... stupid tablet keypads...

@jleben
Member
jleben commented Feb 11, 2013

Related to autosave: #725

@scztt
Collaborator
scztt commented Apr 17, 2015

This is admirably handled in the JetBrains IDE apps. They keep an internal document history that can be logged and diff'd almost exactly like a git history - you can even restore deleted files. I've found it's honestly one of the killer features of that suite.

@scztt scztt added this to the future milestone Apr 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment