From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: autorevert and vc Date: Tue, 30 Mar 2004 09:17:36 -0600 (CST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200403301517.i2UFHa613876@raven.dms.auburn.edu> References: <200403290352.i2T3qTP07266@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1080661730 20447 80.91.224.253 (30 Mar 2004 15:48:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 30 Mar 2004 15:48:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 30 17:48:41 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B8LTl-0000dR-00 for ; Tue, 30 Mar 2004 17:48:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B8LTl-0001rZ-00 for ; Tue, 30 Mar 2004 17:48:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B8LTT-0001nG-7k for emacs-devel@quimby.gnus.org; Tue, 30 Mar 2004 10:48:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B8LT5-0001dp-71 for emacs-devel@gnu.org; Tue, 30 Mar 2004 10:47:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B8LSW-0001Sn-7b for emacs-devel@gnu.org; Tue, 30 Mar 2004 10:47:56 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B8L1l-0003NY-Uj for emacs-devel@gnu.org; Tue, 30 Mar 2004 10:19:46 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i2UFJhKt028921; Tue, 30 Mar 2004 09:19:43 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i2UFHa613876; Tue, 30 Mar 2004 09:17:36 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan Monnier on 28 Mar 2004 23:24:03 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:21093 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21093 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.