[scribus] [1.4.0] autosave file exists

[ale rimoldi]

hi john,

> On Sun, 29 Jan 2012 11:11:31 +0100
> JLuc <jluc at no-log.org> wrote:
> > 
> > Well, in cas of a user problem (not a scribus one), it enables to
> > get a previous correct version. But ONE version only is a not
> > enough. :-)
> > 
> > It'd be better to benefit of 5 or 10 or 100 previous versions.
> > (number should be part of the settings).
> > That's http://bugs.scribus.net/view.php?id=6253
> > 
> > And the .autosave should not be in the same folder,
> > but in a dedicated autosave folder (specified in the settings).
> > Thats http://bugs.scribus.net/view.php?id=10220
> > 
> > JLuc
> > 
> Decades ago Univac had an editor that preserved the original file
> and then successive deltas that modified the file. That way you
> could back up to any previous edition up to about 5 deltas.
> 
> In today's world of plentiful disk space perhaps this delta method
> is not optimal. But certainly the ability to go back several
> sessions would be handy. The Vim/Gvim editor saves just one
> edition back, similar but perhaps not identical to the current
> Scribus save method. 
> 
> As noted this would protect not against system error but enable author
> second thoughts. 

nowadays we have revision systems (git, cvs, svn... i use the latter to
manage my files), incremental and revisioned backup systems (apple and
microsoft both deliver one of them included in their OS) and on linux
we even have revisioned file systems...

do we really need the application to leave its traces behind? on top of
it--  as jluc also noticed -- the traces are mostly useless because most
of the time they are empty or exactly the same as the file they refer
to?

sometimes less is more and a bit of order does not hurt (what would you
think if openoffice, gimp, inkscape and your text editor would leave
behind multiple autosave files? the directory with your .SLA project
would be unmanageable!)


as already said: the idea of the .autosave file is a good one, but that
file should be removed once the file has been correctly closed.
if you want to be able to go back in time after the the .SLA file has
been closed, i think that you should use a revision system, they're
pretty ubiquitous nowadays or push for scribus storing the undo
information into the .SLA file and allowing infinite and persistent
undo if you wish so (gimp is going that way: it is planned to put all
the editing history in the XCF files!).

have fun
a.l.e