From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andre Spiegel Newsgroups: gmane.emacs.devel Subject: RE: vc-state always calls heuristic function Date: Wed, 24 Nov 2004 11:55:00 +0100 Message-ID: <1101293700.27530.44.camel@localhost> References: <1B3ACCFD5694A94DBA4E231402B0E9ED57AE5B@mucmail1.sdm.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1101293838 25295 80.91.229.6 (24 Nov 2004 10:57:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 24 Nov 2004 10:57:18 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 24 11:57:10 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CWupi-0007YW-00 for ; Wed, 24 Nov 2004 11:57:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWuyr-0003AX-8M for ged-emacs-devel@m.gmane.org; Wed, 24 Nov 2004 06:06:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CWuxV-0002nG-2L for emacs-devel@gnu.org; Wed, 24 Nov 2004 06:05:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CWuxT-0002lo-FK for emacs-devel@gnu.org; Wed, 24 Nov 2004 06:05:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWuxS-0002l4-Pb for emacs-devel@gnu.org; Wed, 24 Nov 2004 06:05:11 -0500 Original-Received: from [193.113.160.41] (helo=mail.o2.co.uk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CWunw-0004y4-LD for emacs-devel@gnu.org; Wed, 24 Nov 2004 05:55:20 -0500 Original-Received: from [62.225.130.165] (62.225.130.165) by mail.o2.co.uk (7.0.028) (authenticated as andre.spiegel@o2online.de) id 40EC1F6B01A2EE43; Wed, 24 Nov 2004 10:52:30 +0000 Original-To: klaus.berndl@sdm.de In-Reply-To: <1B3ACCFD5694A94DBA4E231402B0E9ED57AE5B@mucmail1.sdm.de> X-Mailer: Evolution 2.0.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30313 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30313 On Wed, 2004-11-24 at 09:39 +0100, klaus.berndl@sdm.de wrote: > Hmm, now i'm confused... ECB needs a function how to get the VC-state. Well, > the user can customize which function ECB should use. But if he should > not use `vc-recompute-state' how he should get fresh-but-slow state?? > If only vc-state is used then tweaking vc-cvs-stay-local wil never take > effect but vc-state always call the heursitic backend-function (and > vc-cvs-state-heuristic also never uses vc-cvs-stay-local)... Would it better > to use the backend function itself - so vc-cvs-state when a user wants fresh > state (ECB allows to specify different "get-state"-functions for different > backends...)?? VC/CVS actually does it this way: When you visit a file, it always uses just the heuristic to get the state (comparing file times), regardless of the setting of vc-cvs-stay-local. This is because the "fresh-but-slow" state is determined by calling "cvs status" on the file, and this was deemed unacceptably slow if done at visiting time under any conditions. The state is updated by calling vc-recompute-state prior to vc-next-action (C-x v v). IF vc-cvs-stay-local is nil, then this does in fact call "cvs status" to get the "fresh-but-slow-state", but if vc-cvs-stay-local is t, then it just compares the file times again. The bottom line for you is this: If you use vc-state to get the version control state, then you get the same policy that VC uses. I don't see any harm if you let people use vc-recompute-state as a replacement function, but then (a) people must make sure to set vc-cvs-stay-local to nil, and (b) fetching the state over the network under all conditions was deemed unacceptably slow in VC, and perhaps it's the same for your problem as well. You should NEVER call vc-cvs-state or vc-cvs-state-heuristic directly however, because that would mess up VC's caching of these values in the vc-state property. All things considered, I'd say stick with the vc-state function, and educate your users how to tweak its behaviour via vc-cvs-stay-local.