Re: autorevert and vc

[Luc Teirlinck <teirllm@dms.auburn.edu>]

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.