[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4515: 23.1.50; Reverting changes on versioned file does not revert v

From: Dan Nicolaescu
Subject: bug#4515: 23.1.50; Reverting changes on versioned file does not revert vc modeline status
Date: Wed, 23 Sep 2009 11:36:06 -0700 (PDT)

Óscar Fuentes <address@hidden> writes:

  > Dan Nicolaescu <address@hidden> writes:
  > > address@hidden "(Óscar" Fuentes) writes:
  > >
  > >   > Please write in English if possible, because the Emacs maintainers
  > >   > usually do not have translators to read other languages for them.
  > >   > 
  > >   > Your bug report will be posted to the address@hidden mailing list.
  > >   > 
  > >   > Please describe exactly what actions triggered the bug
  > >   > and the precise symptoms of the bug:
  > >   > 
  > >   > When a modified versioned file is edited in such a way that the
  > >   > modifications undoes previous changes to the file, after saving it the
  > >   > VC-dired buffer for the working copy is automatically updated showing
  > >   > that the status of the file is "up to date", but the VC modeline for 
  > >   > buffer that visits the file does not change and keeps indicating that
  > >   > the file state is "locally modified".
  > >
  > > Can you please describe step by step the actions necessary to reproduce
  > > this starting from emacs -Q?
  > emacs -Q
  > C-x C-f some-versioned-unmodified-file
  > do some edition
  > C-x C-s (the VC status modeline indicator changes from `-' to `:')
  > undo previous edition
  > C-x C-s
  > Now you just turned the file to its original state and is unmodified as
  > far as the version control system is concerned, but the VC modeline
  > keeps showing `:' (for example Bzr:836) indicating that the file is
  > edited. After saving a versioned file, VC should check if the VC backend
  > flags the file as edited and update the modeline accordingly.

You can do M-x revert-buffer or C-x v u and that would reset the VC
state accordingly.
Checking for this condition after each save is prohibitively expensive,
and it's an extremely rare event, so it's not worth optimizing for.
So this is neither a bug, not something worth improving.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]