[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: an inconvenient difference in Emacs 22
From: |
Giorgos Keramidas |
Subject: |
Re: an inconvenient difference in Emacs 22 |
Date: |
Sat, 22 Sep 2007 23:56:33 +0300 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (berkeley-unix) |
On 21 Sep 2007 22:21:54 -0400, Steve Newcomb <srn@coolheads.com> wrote:
> In the end, an even better approach, at least for our purposes, may be
> global-auto-revert-mode. I am chagrined to discover that this mode
> has been around for a while, and I just didn't know it. Until I read
> your suggestions, I had never understood that, in the jargon of Emacs,
> "revert-buffer", means "update the buffer".
The name was probably chosen because it "reverts any in-memory
modifications the buffer includes, and reloads its contents to what is
stored on disk."
It may seem a bit unintuitive, but now you know it's there and another
cool feature of Emacs can make your every day life easier :-)
> I'm curious about this usage of the word "revert". "Revert" normally
> connotes some sort of retrograde motion. As far as I know, it never
> connotes forward motion at all, much less forward motion undertaken to
> catch up with someone else's forward motion. But, until I'm
> corrected, that's how I'll understand "revert" in the context of
> Emacs.
"revert" is also used in the Source Code Management world. There is at
least one particular use of "revert" which matches precisely the meaning
of "revert" in Emacs lore.
<somewhat-off-topic-but-probably-useful-to-know>
In the Perforce SCM, every file of a local workspace is checked-out as
read-only[1]. Before making local changes, Perforce users are expected
to run "p4 edit filename" or "p4 open filename", to notify the central
repository server that they are going to make changes to the file.
Once a file is "opened", it becomes a part of the active changelist and
it no longer receives updates from the repository, even if another
developer modifies it. It is something like "a local buffer for a
historical copy of the file's contents".
If the developer wants to throw away all local changes, and synchronize
her copy with the latest version of the file in the repository, then the
appropriate incantation is:
p4 revert filename
This does not necessarily "revert" the file contents to the version
which had been historically checked out, but it "reverts the local file
copy to the latest version of the file in the repository".
When a Perforce user runs "p4 revert", the same sort of "forward
movement" you describe with Emacs buffer contents happens if another
developer has checked-in changes in the mean time :-)
Notes
*****
[1] There is an option to check out read-write copies, but it is
generally frowned upon and it makes life somewhat harder down the
road. But that's irrelevant here.
</somewhat-off-topic-but-probably-useful-to-know>