|
|
Freeverse, Inc.'s SOUND STUDIO 3.5.5 - Sound Studio is for anyone who needs to record or edit audio with a professional tool, but at a consumer price. Perfect for Podcasts, Music, More! Now updated for OS X 10.5 Leopard. <http://www.freeverse.com/soundstudio>
|
TidBITS TidBITS TidBITS Talk 
Ideal auto-save behavior kevinv - 03:00pm Jun 1, 2004 PST[Better late than never on breaking this into its own thread. -Adam] --On Tuesday, May 25, 2004 7:10 AM -0700 David Ross
<dr  davidrossconsultant.com> wrote: >>>**Auto-Save** -- >> >> IMO, this should be a system-level service, not something every >> application should reinvent. It's ridiculous that there's still such a >> thing as losing unsaved data. > > How do you do this? If you use the hypercard/filemaker model, then > backing out changes becomes difficult. If I do something in word that's > just fubar'd, I can quit without saving, and bang! Bad changes begone. > If it's autosaved, I can't do that. > > Do you save multiple versions of the file? If so, when? Where? What do > you do on application quit? > > There's no "one size fits all here". I work with CAD users and I just can't see what makes sense for CAD to make sense for Word or Photoshop. This has to be application specific. BUT BUT BUT what I would love is that the system support generational saves such that you have the last x number of saves to which you can refer. Architects are continually using the restore function of the daily backup to get that file as it was a day or two ago. Heh, as I've been reading these I've been thinking about how many of them
have been available in the CADD package I've been supporting for quite some
time now (Windows only MicroStation from Bentley Systems). We've always
had auto-save (and have always had the same problem of needing to restore
past versions from backup) but they've recently added a feature that allows
the user to take snapshots of the file at certain stages. The current
state is then saved to the file. Users can select the file at different states and compare them, showing
additions/changes/moves/deletions between the states. Much like
Photoshop's history brush allows, users can recover just parts of the
different states also (a restore from backup returns everything the way it
was). To save disk space, only changes since the previous snapshot are actually
stored. Past snapshots can also be merged out so that the file size can be
controlled. I prefer this to Word's track every little change mode. I don't really
want to know every character removal and re-add, but it is useful to save
the state of the document at the end of the day, or at submittal time, so I
can roll back through several days of work. CADD software also has tools for working with large volumes of data, such
as the ability to reference read-only versions of other files. So if you
break your book up into chapters, you can still reference the other
chapters into the working file so they are available for
searching/reviewing. You can print from the main file and have all the
other files print in their appropriate places. Word has a master document concept but I've had problems with getting it to
work reliably, especially with something like a Environmental Impact
Studies that are large, and involve lots of graphical data (and even CADD
data). We used Quark for these and are switching to inDesign. Kevin
Mark as Read
Carl S Zimmerman
-
Jun 1, 2004 3:55 pm
(#1 Total: 5)
|
 |
|
|
 |
| Posts: 66 |
Re: System-level backup/recovery vs. autosave/undo
Under the topic "Thoughts about WriteRight" (msg#35), "dr" wrote: what I would love is that the system support generational saves such that you have the last x number of saves to which you can refer. and in the same thread (msg#36), Harro de Jong wrote: On the VMS system, you'd get a new file every time you saved. A version number was appended to the file name. FrameMaker can be set to back up the previous version of your document. Yes, VAX/VMS and some other mainframe-caliber OSes fully support
versioning of files of every kind. In the best systems (sometimes
combinations of the OS and third-party products), that versioning is
also fully integrated with file backup/recovery systems, with
management tools accessible to (and customizable by) the individual
user. With MacOS X being a multi-user system, and with
multi-gigabyte online storage, we're long overdue for similar systems
and tools in our favorite working environment. However, autosave and undo (whether in the hypothetical WriteRight or
in any other application) should neither require nor utilize
versioning. They should be solely a function of the application in
the current (or the recovered) session. (As mentioned in an earlier
posting, autosave should be sufficiently context-sensitive to happen
only at useful points (e.g., not in the middle of a word) and should
be transparent to the user.) On the other hand, creation of a new
file version by the application (and OS) should only (and always)
occur when the user executes a Save (or, to use an older terminology,
Checkpoint) command; thus each version can represent a clear milepost
in the user's project development. As a further enhancement, metadata associated with a file version
(again at the OS level) could be used to store brief descriptive
information about what distinguishes this version from earlier ones.
As examples, for a document which is a book manuscript, the version
metadata (from the user) might say "added new Appendix B" or "revised
Ch.11". An additional advantage of a file versioning system is that it could
provide native support at the OS level for some kinds of
configuration management tools. That should considerably reduce the
need for them to use complex proprietary databases, thus making them
more affordable and encouraging their wider use. CSZ
|
|
 |  |
Nigel Stanger (apparently)
-
Jun 1, 2004 3:57 pm
(#2 Total: 5)
|
 |
|
|
via email - Dunedin, New Zealand |
|
|
 |
| Posts: 448 |
Re: Ideal auto-save behavior
On 2/6/2004 11:00 AM, "kevinv" <kevin  vanhaaren.net> spake thus:
> To save disk space, only changes since the previous snapshot are actually
> stored. Past snapshots can also be merged out so that the file size can be
> controlled.
I do exactly the same thing with all my documents using CVS. It's a little
non-trivial to set up and doesn't work very well with binary files, but I'm
a geek and do everything in LaTeX, so neither of these are a problem.
I had a case in point a week ago where I had to retrieve a rather old
version of a LaTeX package I developed for writing exam papers (very
specific to our University, so there's probably little point in asking me
for a copy :) In effect I just said to CVS "give me the 1.2 release of this
package", and presto! Time travel is possible :)
--
Nigel Stanger, mailto:nstanger  infoscience.otago.ac.nz
Dept. of Information Science, http://divcom.otago.ac.nz/infosci/
University of Otago, Dunedin, NEW ZEALAND. XNS: =Nigel Stanger
|
|
 |  |
Nigel Stanger (apparently)
-
Jun 3, 2004 5:59 am
(#3 Total: 5)
|
 |
|
|
via email - Dunedin, New Zealand |
|
|
 |
| Posts: 448 |
Re: Ideal auto-save behavior
On 2/6/2004 11:55 AM, "Carl S Zimmerman" <csz_stl  swbell.net> spake thus:
> Yes, VAX/VMS and some other mainframe-caliber OSes fully support
> versioning of files of every kind.
Oddly enough, the original Macintosh File System (MFS) had version numbers,
but they were never used by anything. I think they were removed when HFS was
introduced.
--
Nigel Stanger, mailto:nstanger  infoscience.otago.ac.nz
Dept. of Information Science, http://divcom.otago.ac.nz/infosci/
University of Otago, Dunedin, NEW ZEALAND. XNS: =Nigel Stanger
|
|
 |  |
bigstevemac (apparently)
-
Jun 7, 2004 8:48 am
(#4 Total: 5)
|
 |
|
|
 |
| Posts: 24 |
Re: Ideal auto-save behavior
If we all saved religiously (and we do, don't we?), then there'd be no need
for auto-save functions. I save to the extent that I have a twitch in my
left hand whereby the thumb and forefinger hit a brace of keys every few
seconds, and certainly every time I pause for more than the briefest of
moments.
As a result, I find myself feeling rather naked, rather vulnerable, rather ‹
dare I say it ‹ *unprotected* when I'm FileMaking. A longtime Mac user, I
feel the urge to save every time I ask my 'book to do anything more
strenuous than a bit of text entry. But in FileMaker, I can't do that (or
can I? I've never been able to figure out how). Functions such as changing
the input script have, in the past, been more than enough to push even a
moderately unstable system over the edge into a crash, and any time I try to
do something along those lines in FMPro, I find my left hand twitching.
Autosave might be doing its thing, but I still feel exposed...
Steve
|
|
 |  |
Nik (apparently)
-
Jun 8, 2004 4:57 am
(#5 Total: 5)
|
 |
|
|
 |
| Posts: 386 |
Re: Ideal auto-save behavior
On Jun 7, 2004, at 10:48 AM, Big Steve wrote:
> A longtime Mac user, I
> feel the urge to save every time I ask my 'book to do anything more
> strenuous than a bit of text entry. But in FileMaker, I can't do that
> (or
> can I?
The script step called "Flush Cache to Disk" is identical to saving. It
will force Filemaker to immediately save all changes in RAM to disk.
Normally, FMPro does this regularly and it isn't a big deal, but I like
to add this step at the end of all important scripts (or throughout the
script sometimes).
No reason why you couldn't attach a keyboard command to a 1-step Flush
Cache script and call it your save reflex script. :)
--Nik
|
|
|
TidBITS TidBITS TidBITS Talk Ideal auto-save behavior
|
|