Yeah, I think we originally talked about "File->Revert" (it sounded
too much like CVS terms to me ;-), but decided to go with the safe
"what people were already using" option for the short term. 

I'm sort of uncomfortable with including this feature at all, but
mostly because I'm becoming increasingly unhappy with the
load->buffer->save flow used in most applications...and "Reload"
smacks of this viewpoint ;-)

When I'm typing in a document, I'm not actually changing the document,
my program's tell me, I'm just typing in a buffer that I can flash to
disk to change the *actual* document.

So I'm a little bit afraid that people will think "Reload" just
refreshes their current document and might lose work this way? Or
something like that. Just throwing out ideas, what about "Re-open" or
"Reload from disk" or something to clarify that this will grab the
latest document on disk, throwing away your current buffered changes?

Well, on Windoze at least the usual Revert behaviour is to pop up an
alert if there are any unsaved changes, warning that they'll be lost. 
While I'm all for minimizing the number of alerts a user sees, maybe
that's the best we can do.

As for the whole load->buffer->save concept, I've heard some
interesting anecdotes recently from the other Sun usability guys about
their attempts to change that in the past... one such is posted here
as a taster :)

> The I-haven't-saved-yet method of version control is an example of
> users repurposing a technology. Explicit Save wasn't originally
> designed for version control, but users adopted it for that new
> purpose. That creates an additional demand on designers--to provide
a
> substitute not only for the original function that Save was designed
> to serve, but also a substitute for the version-control function
that
> the _users_ "redesigned" Save to serve.
> 
> Users rely on explicit Save for version control to such an extent,
> that many users hate the type of autosaving that replaces the "real"
> previously saved version.  Many users are more comfortable with
> autosaving that saves to a special recovery file that's invisible
> until the user tries to reopen a data object that closed abnormally.
>  (The app offers to restore the object from that recovery file.) 
Many
> users dislike autosaving at object closing, because it destroys
their
> use of Save as version control; they want a confirmation dialog.
> 
> The I-haven't-Saved-yet method requires no work to mark a particular
> version; the user simply makes a point of not saving yet.  Several
> attempts to provide version control in lieu of explicit Save have
> failed (e.g., unlimited Undo, Corel's versioning), because they
> required too much work for marking a particular version.  Automatic
> versioning methods such as unlimited Undo require the user to wade
> through the many versions until guessing that they've reached the
> desired one.  Corel added the user's ability to explicitly save a
> version and to manally mark existing versions, even autosaved ones.
>  But those require positive actions by the user, which aren't as
easy
> as the passive action of just not saving yet.
> 
> So getting rid of explicit Save requires solving not just the
original
> problem that Save was designed for, but requires also providing an
> equally easy substitute for the version control for which Save has
> been adopted.

Wouldn't it be grand if version control was built into the file
system. I think VMS used to actually do this even.

I'm confused. What's the bug here?

In case it's about auto-save and versioning:
  1) Auto-save is long overdue.
  2) File->Stamp Version, with access key 'S' and shortcut Ctrl+S,
     should provide a clean migration. A wax seal would be an
     appealing icon to me, but who else would recognize it?
  3) A versioning scheme is needed since most of us don't use VMS.
     Something like `basename-CCYY-MM-DD-HH-MM-SS' should suffice.
     (Star Trek fans might prefer `basename-CCYYMM.DD-HHMM.SS')
  4) Revert might be better as Revert..., showing a dialog listing
     versions.

Every app should be using GTK_STOCK to make it easier if we can ever agree that
changing the label from Revert to Reload is a good idea.  I think Revert/Reload
is different enough from Refresh in a browser that merging the two could be
hazardous.  

I am for consistency and as usual I'm against this change.  (see also bug 152592
which advocates a consistent keybinding for Revert.  still unconfirmed)
Some applications such as Adobe Photoshop use Revert the way I think it really
deserves and rather than just a simpler reload it also preserves the undo
history and Revert becomes just another undoable change.  Kickass, wish more
programs did Revert like that, then we wouldn't even need to consider the Reload
idea which is subtely different.  

(Comment #3 there do exist filesystems which are fully versioned and everytime
you save you get a new file.  If I had a ridiculously large harddrive I might
just use such a system at least for my homediretory.  I think whatever the
NetApp filer uses must be one of those fully versioned filesystems.)

I agree that Revert is confusing (in all my years using GNOME, it has never been entirely clear what it means). If the item is going to stay, something like "Discard Changes" might be a better solution.

That said, I agree with comment 5 - this is conceptually identical to Undo, so I'm not entirely sure how necessary this is.

Let's say this is fixed for now.

https://git.gnome.org/browse/gnome-devel-docs/commit/?id=e6bcf2abe5a83b62f47a86d2312ad5ff163084e0