[scribus] [1.4.0] autosave file exists

[john Culleton]

On Mon, 30 Jan 2012 08:51:00 +0100
ale rimoldi <ale.comp_06 at xox.ch> wrote:

> 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
> 
> ___
> Scribus Mailing List: scribus at lists.scribus.net
> Edit your options or unsubscribe:
> http://lists.scribus.net/mailman/listinfo/scribus
> See also:
> http://wiki.scribus.net
> http://forums.scribus.net
> 
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
>               http://www.doteasy.com 

The delta system is similar to the undo system except each delta 
is a separate file listing just the changes, like a patch file in Unix 
or Linux. That saves disk space compared to full copies
(autosave) and does not clutter up the sla file with undo
information. So the delta system is worth considering. 

-- 
John Culleton
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html

"Create Book Covers with Scribus"
http://www.booklocker.com/books/4055.html