autorevert and vc

autorevert and vc

[Luc Teirlinck]

As I already said before, the one part of the recent changes to
autorevert.el (prior to the ones I made) which I did not check are
the vc-part of those changes.  There seem to be bugs, or at the very
least nuisance features, associated with them.

Unlike the non-file features, the vc features are enabled by default,
if global-auto-revert-mode is enabled.  If nothing else, one needs a
way to disable them, which the patch below provides.  I personally do
not know enough about vc to do a lot more than that.

If one visit a file that is using RCS, it does not auto-revert, until
one loads 'vc.  Then it auto-reverts every auto-revert-interval
seconds, regardless of whether there is any need for that.

The reasons for this behavior are obvious from the code:

Part of the check of whether the file needs reverting is 
(featurep 'vc).  So no version controlled file, RCS or CVS, will be
auto-reverted until vc is loaded.  Apparently, that does not
automatically happen by visiting a version controlled file.  It does
happen if one does C-x v =.  I do not see what requesting a diff has
to do with requesting auto-reverting.

The following explains the other part of the RCS-problem:
     
     ((eq backend 'RCS)
       ;; TODO:
         )

If vc is loade that code is equivalent with:

((eq backend 'RCS) t)

That can get obnoxious.

When using CVS, automatic reverting every five seconds seems to occur
if there is an out-of-date version backup.  Maybe that is not a bug
and one just should make sure to always delete such obsolete files.

Since RCS and CVS are the two only version control systems I use, I do
not know what happens with other systems.  But no part of the code
even _tries_ to handle them.

I really do not know enough about vc to investigate this further.

However, I believe that, even though vc-mode is not a major mode, it
plays a somewhat similar role in as far as Auto-Revert mode is
concerned.  Hence, I propose the following patch which would allow to
include vc-mode in global-auto-revert-ignore-modes.   Are there any
objections to this patch?

===File ~/autorevert-diff===================================
*** autorevert.el	28 Mar 2004 07:51:54 -0600	1.27
--- autorevert.el	28 Mar 2004 19:42:05 -0600	
***************
*** 181,187 ****
    :type 'boolean)
  
  (defcustom global-auto-revert-ignore-modes '()
!   "List of major modes Global Auto-Revert Mode should not check."
    :group 'auto-revert
    :type '(repeat sexp))
  
--- 181,189 ----
    :type 'boolean)
  
  (defcustom global-auto-revert-ignore-modes '()
!   "List of major modes Global Auto-Revert Mode should not check.
! This list can also include `vc-mode', meaning that Auto-Revert
! Mode should not check version controlled buffers."
    :group 'auto-revert
    :type '(repeat sexp))
  
***************
*** 276,283 ****
        (and
         global-auto-revert-mode
         (not global-auto-revert-ignore-buffer)
!        (not (memq major-mode
! 		  global-auto-revert-ignore-modes)))))
  
  (defun auto-revert-vc-cvs-file-version (file)
    "Get version of FILE by reading control file on disk."
--- 278,286 ----
        (and
         global-auto-revert-mode
         (not global-auto-revert-ignore-buffer)
!        (not (memq major-mode global-auto-revert-ignore-modes))
!        (not (and (auto-revert-vc-buffer-p)
! 		 (memq 'vc-mode global-auto-revert-ignore-modes))))))
  
  (defun auto-revert-vc-cvs-file-version (file)
    "Get version of FILE by reading control file on disk."
============================================================

Re: autorevert and vc

[Stefan Monnier]

> As I already said before, the one part of the recent changes to
> autorevert.el (prior to the ones I made) which I did not check are
> the vc-part of those changes.  There seem to be bugs, or at the very
> least nuisance features, associated with them.

I'd suggest to completely take them out.
Their implementation is so ugly that it's best to start over from scratch.

If you don't want to take it all out, at least please remove:

 	(if (eq revert 'vc)
 	    (vc-mode-line buffer-file-name))))))

It seems to be redundant and probably results from the fact that the
original author tried to fix a problem and didn't notice when he updated his
code that the current version does

	;; `preserve-modes' avoids changing the (minor) modes.  But we
	;; do want to reset the mode for VC, so we do it explicitly.
	(vc-find-file-hook)

just before which fixes the same problem.

Another thing: why on earth do

  (and (boundp 'vc-mode)
       (string-match "[0-9]" (or vc-mode ""))))

rather than 

  (and (boundp 'vc-mode) (stringp vc-mode)) ?

Also all the CVS-related code needs to be moved to vc-cvs.el.

Finally, I think the idea of doing a `revert' of the file when the file has
not changed is just plain wrong.  If you want to update the VC-state, then
update just the VC-state, but don't additionally revert the buffer.

In other words the VC-state-refresh code should be completely separate
from the file-buffer-refresh code since both can change independently.
It can still all be in autorevert.el, but a refresh of one shouldn't
necessarily force a refresh of another (currently a refresh of the buffer
text forces a refresh of the VC-state, which is OK only because we don't
kow how to check staleness of the VC-state so we use staleness of the
buffer-text as a heuristic that the VC-state might also be stale).


        Stefan

Re: autorevert and vc

[Luc Teirlinck]

Stefan Monnier wrote:

   > As I already said before, the one part of the recent changes to
   > autorevert.el (prior to the ones I made) which I did not check are
   > the vc-part of those changes.  There seem to be bugs, or at the very
   > least nuisance features, associated with them.

   I'd suggest to completely take them out.

I plan to do that.  I guess that would also eliminate the need for the
patch I included.

Sincerely,

Luc.

Re: autorevert and vc

[Luc Teirlinck]

Stefan Monnier wrote:

   In other words the VC-state-refresh code should be completely separate
   from the file-buffer-refresh code since both can change independently.
   It can still all be in autorevert.el, but a refresh of one shouldn't
   necessarily force a refresh of another (currently a refresh of the buffer
   text forces a refresh of the VC-state, which is OK only because we don't
   kow how to check staleness of the VC-state so we use staleness of the
   buffer-text as a heuristic that the VC-state might also be stale).

It apparently does not seem to take that much CPU to update the
VC-state (without reverting the buffer) every five seconds, whether it
is needed or not.  I needed at least twenty version controlled buffers
to make the CPU usage just barely measurable on a 1.7 GHZ dual Xeon.
On the other hand, the problem only occurs while editing the same
version controlled buffer from two distinct Emacs buffers.  Why waste
_any_ CPU if one knows that that situation is not going to occur?  

The patch below takes out all original vc-code, as you suggested.
Then it takes care of the problem that code was intended to fix by
calling `vc-find-file-hook' unconditionally if the user requests that
through a customizable variable.  The default is nil, do not do this.
If the user has a reasonably fast machine and worries about the
problem, he sets it to t and forgets about it.  If the user knows he
never is going to be in that situation, he keeps it nil.  Otherwise,
he sets it to t whenever the need arises.

Note that my patch works for all version control systems supported by
VC (I checked it for RCS), whereas the original only worked for CVS.

Does this look OK?

===File ~/autorevert-diff1==================================
*** autorevert.el	28 Mar 2004 07:51:54 -0600	1.27
--- autorevert.el	29 Mar 2004 19:39:15 -0600	
***************
*** 70,83 ****
  ;; Dependencies:
  
  (require 'timer)
! (autoload 'dired-get-filename "dired")
! (autoload 'vc-workfile-version "vc-hooks")
! (autoload 'vc-mode-line        "vc-hooks")
! 
! (eval-when-compile
!   (defvar dired-directory)
!   (defvar vc-mode)
!   (require 'cl))
  
  
  ;; Custom Group:
--- 70,77 ----
  ;; Dependencies:
  
  (require 'timer)
! 
! (eval-when-compile (require 'cl))
  
  
  ;; Custom Group:
***************
*** 191,196 ****
--- 185,205 ----
    :group 'auto-revert
    :type 'hook)
  
+ (defcustom auto-revert-check-vc-numbers nil
+   "If non-nil Auto Revert Mode reliably updates version control info.
+ This matters if a version controlled file is edited from several
+ Emacs sessions.  In that case, if changes in one session are saved,
+ any buffers visiting the file in other sessions are updated.
+ However, if the changes are checked in, the version control number
+ in the mode line, as well as other version control related
+ information, may not be properly updated in the other sessions.
+ If you are worried about this, set this variable to a non-nil value.
+ This should not cause excessive CPU usage on a reasonably fast
+ machine, if it does not apply to too many version controlled buffers."
+   :group 'auto-revert
+   :type 'boolean
+   :version "21.4")
+ 
  (defvar global-auto-revert-ignore-buffer nil
    "*When non-nil, Global Auto-Revert Mode will not revert this buffer.
  
***************
*** 279,365 ****
         (not (memq major-mode
  		  global-auto-revert-ignore-modes)))))
  
- (defun auto-revert-vc-cvs-file-version (file)
-   "Get version of FILE by reading control file on disk."
-   (let* ((control "CVS/Entries")
- 	 (name	  (file-name-nondirectory file))
- 	 (path	  (format "%s/%s"
- 			  (file-name-directory file)
- 			  control)))
-     (when (file-exists-p path)
-       (with-temp-buffer
- 	(insert-file-contents-literally path)
- 	(goto-char (point-min))
- 	(when (re-search-forward
- 	       ;; /file.txt/1.3/Mon Sep 15 18:43:20 2003//
- 	       (format "%s/\\([.0-9]+\\)" (regexp-quote name))
- 	       nil t)
- 	  (match-string 1))))))
- 
- (defun auto-revert-vc-buffer-p ()
-   "Check if buffer is version controlled."
-   (and (boundp 'vc-mode)
-        (string-match "[0-9]" (or vc-mode ""))))
- 
- (defun auto-revert-handler-vc ()
-   "Check if version controlled buffer needs revert."
-   ;; [Emacs 1]
-   ;; 1. File is saved	  (*)
-   ;; 2. checkin is done 1.1 -> 1.2
-   ;; 3. VC reverts, so that updated version number is shown in mode line
-   ;;
-   ;; Suppose the same file has been opened in another Emacs and
-   ;; autorevert.el is on.
-   ;;
-   ;; [Emacs 2]
-   ;; 1. Step (1) is detected and buffer is reverted.
-   ;; 2. But check in does not always change the file in dis, but possibly only
-   ;;	control files like CVS/Entries
-   ;; 3. The buffer is not reverted to update VC version line.
-   ;;	Incorrect version number 1.1 is shown in this Emacs
-   ;;
-   (when (featurep 'vc)
-     (let* ((file	   (buffer-file-name))
- 	   (backend	   (vc-backend (buffer-file-name)))
- 	   (version-buffer (vc-workfile-version file)))
-       (when (stringp version-buffer)
- 	(cond
- 	 ((eq backend 'CVS)
- 	  (let ((version-file
- 		 (auto-revert-vc-cvs-file-version (buffer-file-name))))
- 	    (and (stringp version-file)
- 		 (not (string-match version-file version-buffer)))))
- 	 ((eq backend 'RCS)
- 	  ;; TODO:
- 	  ))))))
- 
  (defun auto-revert-handler ()
    "Revert current buffer, if appropriate.
  This is an internal function used by Auto-Revert Mode."
    (unless (buffer-modified-p)
      (let (revert)
!       (cond
!        ((auto-revert-vc-buffer-p)
!  	(when (auto-revert-handler-vc)
!  	  (setq revert 'vc)))
!        ((or (and (buffer-file-name)
! 		 (file-readable-p (buffer-file-name))
! 		 (not (verify-visited-file-modtime (current-buffer))))
! 	    (and (or auto-revert-mode global-auto-revert-non-file-buffers)
! 		 revert-buffer-function
! 		 (boundp 'buffer-stale-function)
! 		 (functionp buffer-stale-function)
! 		 (funcall buffer-stale-function t)))
! 	(setq revert t)))
        (when revert
  	(when auto-revert-verbose
  	  (message "Reverting buffer `%s'." (buffer-name)))
! 	(revert-buffer 'ignore-auto 'dont-ask 'preserve-modes)
! 	;; `preserve-modes' avoids changing the (minor) modes.  But we
! 	;; do want to reset the mode for VC, so we do it explicitly.
! 	(vc-find-file-hook)
!  	(if (eq revert 'vc)
!  	    (vc-mode-line buffer-file-name))))))
  
  (defun auto-revert-buffers ()
    "Revert buffers as specified by Auto-Revert and Global Auto-Revert Mode.
--- 288,315 ----
         (not (memq major-mode
  		  global-auto-revert-ignore-modes)))))
  
  (defun auto-revert-handler ()
    "Revert current buffer, if appropriate.
  This is an internal function used by Auto-Revert Mode."
    (unless (buffer-modified-p)
      (let (revert)
!       (when (or (and (buffer-file-name)
! 		     (file-readable-p (buffer-file-name))
! 		     (not (verify-visited-file-modtime (current-buffer))))
! 		(and (or auto-revert-mode global-auto-revert-non-file-buffers)
! 		     revert-buffer-function
! 		     (boundp 'buffer-stale-function)
! 		     (functionp buffer-stale-function)
! 		     (funcall buffer-stale-function t)))
! 	(setq revert t))
        (when revert
  	(when auto-revert-verbose
  	  (message "Reverting buffer `%s'." (buffer-name)))
! 	(revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))
!       ;; `preserve-modes' avoids changing the (minor) modes.  But we
!       ;; do want to reset the mode for VC, so we do it manually.
!       (when (or revert auto-revert-check-vc-numbers)
! 	(vc-find-file-hook)))))
  
  (defun auto-revert-buffers ()
    "Revert buffers as specified by Auto-Revert and Global Auto-Revert Mode.
============================================================

Re: autorevert and vc

[Luc Teirlinck]

Stefan Monnier wrote:

   In other words the VC-state-refresh code should be completely separate
   from the file-buffer-refresh code since both can change independently.
   It can still all be in autorevert.el, but a refresh of one shouldn't
   necessarily force a refresh of another (currently a refresh of the buffer
   text forces a refresh of the VC-state, which is OK only because we don't
   kow how to check staleness of the VC-state so we use staleness of the
   buffer-text as a heuristic that the VC-state might also be stale).

>From my prior reply:   
   
   It apparently does not seem to take that much CPU to update the
   VC-state (without reverting the buffer) every five seconds, whether
   it is needed or not.  I needed at least twenty version controlled
   buffers to make the CPU usage just barely measurable on a 1.7 GHZ
   dual Xeon.

To be more specific, I did not make very precise measurements, but it
seems to take about 40 CVS controlled buffers for the checking to use
about one percent of CPU where the two processors count for 200
percent.  This probably still means that on very slow machines there
could be a problem if there are very many VC controlled buffers.  I do
not know very much about VC, but at first sight, I would be inclined
to believe that probably the real way to do it would be to check the
file modification times of the control files.  (I do not know enough
about the various VC systems to implement that, assuming it actually
would make sense.)  There seem to be currently six version control
systems supported by VC.  Maybe a function checking staleness of the
vc state for all of them could be useful for other purposes, but I
seem to infer from your comments quoted above, that there currently is
no such function.

The problem with the implementation we are about to take out is that
it only works for one VC system, CVS, and does not seem to work very
reliably for that one.

Sincerely,

Luc.

Re: autorevert and vc

[Stefan Monnier]

> It apparently does not seem to take that much CPU to update the
> VC-state (without reverting the buffer) every five seconds, whether it
> is needed or not.

Of course that depends on the revision control being used.

> The patch below takes out all original vc-code, as you suggested.
> Then it takes care of the problem that code was intended to fix by
> calling `vc-find-file-hook' unconditionally if the user requests that
> through a customizable variable.  The default is nil, do not do this.
> If the user has a reasonably fast machine and worries about the
> problem, he sets it to t and forgets about it.  If the user knows he
> never is going to be in that situation, he keeps it nil.  Otherwise,
> he sets it to t whenever the need arises.

> Note that my patch works for all version control systems supported by
> VC (I checked it for RCS), whereas the original only worked for CVS.

> Does this look OK?

It looks fine to me.
To improve it we can add something like the following in vc-hooks.el:

   (defun vc-stale-state-p (file)
     (vc-call 'stale-state-p file))
   (defun vc-default-stale-state-p (backend file)
     t)

So you can then use `vc-stale-state-p' to check whether you need to call
vc-find-file-hook.  The default is to always return t but backends can
override it with something more precise in case it's possible to determine
freshness more efficiently than doing the refresh.

Pleased check with Andre <spiegel@gnu.org>, to see whether he has a better
idea about what functionality VC should provide.


        Stefan

Re: autorevert and vc

[Andre Spiegel]

On Tue, 2004-03-30 at 17:17, Luc Teirlinck wrote:

> It apparently does not seem to take that much CPU to update the
> VC-state (without reverting the buffer) every five seconds, whether
> it is needed or not. [...] I do not know very much about VC, but at 
> first sight, I would be inclined to believe that probably the real
> way to do it would be to check the file modification times of the
> control files.

When you call vc-find-file-hook to recompute the version control state,
all that happens for CVS, RCS and SCCS is a check of file modification
times or permissions (for MCVS it's similar, SVN and Arch are slightly
more expensive, I think).

The idea is that backends can provide a vc-BACKEND-state-heuristic
function, which guesses the state by doing a fast operation like a
permission check or mtime check.  If no state-heuristic function is
provided, then each computation of the state likely involves an
expensive call to the backend system.

So, you might fine-tune your algorithm to only re-compute the vc-state
every five seconds *if* the backend has a state-heuristic function. 
(You can use vc-find-backend-function to determine that.)

Stefan's suggestion (vc-stale-state-p) is potentially more generic, but
perhaps it's better to wait until there is a backend where the existing
mechanism really isn't expressive enough.  Stefan, what do you think?

Re: autorevert and vc

[Stefan Monnier]

> When you call vc-find-file-hook to recompute the version control state,
> all that happens for CVS, RCS and SCCS is a check of file modification
> times or permissions (for MCVS it's similar, SVN and Arch are slightly
> more expensive, I think).

> The idea is that backends can provide a vc-BACKEND-state-heuristic
> function, which guesses the state by doing a fast operation like a
> permission check or mtime check.  If no state-heuristic function is
> provided, then each computation of the state likely involves an
> expensive call to the backend system.

Actually in some backends, neirther `state' nor `state-heuristic' is used
because the heuristic state is computed directly by vc-BACKEND-registered.
In others (such as vc-arch.el), there is no `state-heuristic' but the
`state' operation is very fast (heuristic).

> So, you might fine-tune your algorithm to only re-compute the vc-state
> every five seconds *if* the backend has a state-heuristic function.
> (You can use vc-find-backend-function to determine that.)

Sounds fair.  I should adjust vc-arch accordingly, which is probably the
right thihng to do anyway.

> Stefan's suggestion (vc-stale-state-p) is potentially more generic, but
> perhaps it's better to wait until there is a backend where the existing
> mechanism really isn't expressive enough.  Stefan, what do you think?

No preference.


        Stefan

Re: autorevert and vc

[Luc Teirlinck]

Stefan Monnier wrote:

   > So, you might fine-tune your algorithm to only re-compute the vc-state
   > every five seconds *if* the backend has a state-heuristic function.
   > (You can use vc-find-backend-function to determine that.)

   Sounds fair.  I should adjust vc-arch accordingly, which is probably the
   right thihng to do anyway.

In that case, the suggested test would be meaningless for the current
six members of `vc-handled-backends'.  Indeed Arch is the _only_ one
of the six without a state-heuristic function, as determined by
`vc-find-backend-function'.  What if I just commit my patch as is and
then we can always add improvements later?  

One alternative is provided by the diff below, but I do not know
whether the added flexibility would be worth the corresponding added
complexity.  (I did neither carefully check nor test the patch, but
its intent is, I believe, clear, and the intent is what we are
discussing right now.)

Note that this is a variable whose default value is nil.  So by default,
the automatic updating every five seconds does _not_ take place.

===File ~/autorevert-diff3==================================
diff -c /home/teirllm/autorevert.save.el /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el
*** /home/teirllm/autorevert.save.el	Mon Mar 29 19:47:20 2004
--- /home/teirllm/emacscvsdir/emacs/lisp/autorevert.el	Tue Mar 30 19:36:24 2004
***************
*** 187,203 ****
  
  (defcustom auto-revert-check-vc-numbers nil
    "If non-nil Auto Revert Mode reliably updates version control info.
  This matters if a version controlled file is edited from several
! Emacs sessions.  In that case, if changes in one session are saved,
! any buffers visiting the file in other sessions are updated.
! However, if the changes are checked in, the version control number
! in the mode line, as well as other version control related
! information, may not be properly updated in the other sessions.
! If you are worried about this, set this variable to a non-nil value.
! This should not cause excessive CPU usage on a reasonably fast
! machine, if it does not apply to too many version controlled buffers."
    :group 'auto-revert
!   :type 'boolean
    :version "21.4")
  
  (defvar global-auto-revert-ignore-buffer nil
--- 187,218 ----
  
  (defcustom auto-revert-check-vc-numbers nil
    "If non-nil Auto Revert Mode reliably updates version control info.
+ The value is a list of version control systems, for which all
+ version control info will be updated reliably.  The valid
+ elements are nil and the members of `vc-handled-backends',
+ currently `RCS', `CVS', `SVN', `SCCS', `Arch', and `MCVS'.
+ Including nil in the list will just detect that a priorly
+ non-registered file has been put under version control.
+ 
  This matters if a version controlled file is edited from several
! Emacs sessions.  In that case, if changes in one session are
! saved, any buffers visiting the file in other sessions are
! reverted and their version control info is updated.  However, if
! the saved changes are later checked in, without further unsaved
! changes, the version control number in the mode line, as well as
! other version control related information, may not be properly
! updated in the other sessions.  If you are worried about this,
! set this variable to a non-nil value.
! 
! This currently works by automatically updating the version
! control info every `auto-revert-interval' seconds.  On a slow
! computer with a large number of version controlled buffers, this
! could lead to excessive CPU usage.  Also, CPU usage depends
! heavily on the version control system."
    :group 'auto-revert
!   :type '(choice (const :tag "Detect registration" nil)
! 		 (const RCS) (const CVS) (const SVN)
! 		 (const SCCS) (const MCVS) (const Arch))
    :version "21.4")
  
  (defvar global-auto-revert-ignore-buffer nil
***************
*** 309,315 ****
  	(revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))
        ;; `preserve-modes' avoids changing the (minor) modes.  But we
        ;; do want to reset the mode for VC, so we do it manually.
!       (when (or revert auto-revert-check-vc-numbers)
  	(vc-find-file-hook)))))
  
  (defun auto-revert-buffers ()
--- 324,333 ----
  	(revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))
        ;; `preserve-modes' avoids changing the (minor) modes.  But we
        ;; do want to reset the mode for VC, so we do it manually.
!       (when (or revert
! 		(and buffer-file-name
! 		     (memq (vc-backend buffer-file-name)
! 			   auto-revert-check-vc-numbers)))
  	(vc-find-file-hook)))))
  
  (defun auto-revert-buffers ()

Diff finished.  Tue Mar 30 19:36:33 2004
============================================================

Re: autorevert and vc

[Luc Teirlinck]

>From my previous message:

   (I did neither carefully check nor test the patch, but
   its intent is, I believe, clear, ... 

In particular, the defcustom needs a set, not a choice.

Sincerely,

Luc.

Re: autorevert and vc

[Stefan Monnier]

> In that case, the suggested test would be meaningless for the current
> six members of `vc-handled-backends'.  Indeed Arch is the _only_ one
> of the six without a state-heuristic function, as determined by
> `vc-find-backend-function'.  What if I just commit my patch as is and
> then we can always add improvements later?

Agreed.

> One alternative is provided by the diff below, but I do not know
> whether the added flexibility would be worth the corresponding added
> complexity.

Indeed, I don't think it's worth it.


        Stefan

Re: autorevert and vc

[Jari Aalto]

* Mon 2004-03-29 Luc Teirlinck <teirllm <AT> dms.auburn.edu> gmane.emacs.devel
* <http://groups.google.com/groups?oi=djq&as_umsgid=%3C200403300227.i2U2Rp111731@raven.dms.auburn.edu>
| Stefan Monnier wrote:
| 
| On the other hand, the problem only occurs while editing the same
| version controlled buffer from two distinct Emacs buffers.  Why waste
| _any_ CPU if one knows that that situation is not going to occur?  

I give an example where occurs. I have home WLAN with several
computers that share the disks via SAMBA to Windows and Linux
machines. Many times when I sit on one PC and find a problem that I
fix. But I don't necessarily remember that the same file is already
open in another computer and its Emacs buffer that I worked yesterday.

VC buffers should also note changes on disk, when they are modifies by
3rd party programs.

Jari

-- 
http://tiny-tools.sourceforge.net/
Swatch @time   http://www.mir.com.my/iTime/itime.htm
               http://www.ryanthiessen.com/swatch/resources.htm
Use Licenses!  http://www.linuxjournal.com/article.php?sid=6225
Which Licence? http://www.linuxjournal.com/article.php?sid=4825
OSI Licences   http://www.opensource.org/licenses/

Re: autorevert and vc

[Luc Teirlinck]

Jari Aalto wrote:
   
   | On the other hand, the problem only occurs while editing the same
   | version controlled buffer from two distinct Emacs buffers.  Why waste
   | _any_ CPU if one knows that that situation is not going to occur?  

   I give an example where occurs.

I was not contesting that the situation _can_ occur.  To state more
precisely what I meant:

Why should a particular user waste any CPU if that user knows that the
situation is not going to occur for him?

Since yesterday evening, there is a customizable variable
auto-revert-check-vc-info that works for all supported VC systems.
Setting it to t will update all VC info every auto-revert-interval
seconds.  The default is nil.  In personal rudimentary testing, it did
not seem to consume terribly much CPU for RCS and CVS.  I tested on a
1.7 GHZ dual Xeon.  I did not test the four other supported systems.
I do not know anything about them.  I did not yet write a NEWS entry,
but I will.

If there would be performance problems for certain VC systems, one
could try to take care of them, for instance using Stefan's idea of a
`vc-stale-state-p' function.

Sincerely,

Luc.