From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: behavior of vc-recompute-state in combination with vc-cvs-stay-local is t Date: Mon, 29 Nov 2004 17:31:27 +0100 Message-ID: <1B3ACCFD5694A94DBA4E231402B0E9ED57AECB@mucmail1.sdm.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1101745925 8798 80.91.229.6 (29 Nov 2004 16:32:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2004 16:32:05 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 29 17:31:58 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 1CYoRS-00023x-00 for ; Mon, 29 Nov 2004 17:31:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CYoaq-0004IY-O7 for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2004 11:41:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CYoak-0004IJ-6U for emacs-devel@gnu.org; Mon, 29 Nov 2004 11:41:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CYoaj-0004I7-Ly for emacs-devel@gnu.org; Mon, 29 Nov 2004 11:41:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CYoaj-0004I4-HM for emacs-devel@gnu.org; Mon, 29 Nov 2004 11:41:33 -0500 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CYoR1-000658-Q3; Mon, 29 Nov 2004 11:31:32 -0500 Original-Received: from localhost ([127.0.0.1] helo=world1.sdm.de) by world1.sdm.de (MTA) via esmtp id 1CYoR1-0007tI-Aq; Mon, 29 Nov 2004 17:31:31 +0100 Original-Received: from mucns1.muc.sdm.de ([193.102.180.22]) by world1.sdm.de (MTA) via esmtp id 1CYoQz-0007tA-1f; Mon, 29 Nov 2004 17:31:29 +0100 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) id 1CYoQz-00012n-06; Mon, 29 Nov 2004 17:31:29 +0100 Original-Received: from mucmail1.sdm.de ([193.102.180.175]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Nov 2004 17:31:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: behavior of vc-recompute-state in combination with vc-cvs-stay-local is t Thread-Index: AcTSFBnFyZlG0IzFRJC3ZmXPgP1tjgEGj0Qw Original-To: X-OriginalArrivalTime: 29 Nov 2004 16:31:28.0313 (UTC) FILETIME=[E04CF290:01C4D630] 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:30493 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30493 One more question to that topic: (Yes, i know, that currently vc-recompute-state is not really an "official" interface of the VC-package but nevertheless i'm wondering if the folliwng behavior is wanted and if yes why? This is the current implementation (21.3.1) of vc-recompute-state: (defun vc-recompute-state (file) "Force a recomputation of the version control state of FILE. The state is computed using the exact, and possibly expensive function `vc-BACKEND-state', not the heuristic." (vc-file-setprop file 'vc-state (vc-call state file))) which calls in turn for CVS-files: (defun vc-cvs-state (file) "CVS-specific version of `vc-state'." (if (vc-cvs-stay-local-p file) (let ((state (vc-file-getprop file 'vc-state))) ;; If we should stay local, use the heuristic but only if ;; we don't have a more precise state already available. (if (memq state '(up-to-date edited)) (vc-cvs-state-heuristic file) state)) (with-temp-buffer (cd (file-name-directory file)) (vc-do-command t 0 "cvs" file "status") (vc-cvs-parse-status t)))) well, suppose the folliwng scenario: 1. Staring emacs with emacs -q -no-site-file (i.e. fresh) (vc-cvs-stay-local is t) 2. (require 'vc) (require 'vc-hooks) 3. Running (vc-recompute-state = "/a/file/under/lokal-repository-CVS/file.txt") =3D=3D> returns a valid state (e.g. up-to-date) 4. Running (vc-recompute-state = "/a/file/under/remote-repository-CVS/file.txt") =3D=3D> returns always nil, because the state-binding in the = vc-cvs-state is always nil for that file. I thought a combination of vc-recompute-state and vc-cvs-stay-local is t = returns always a state, regardless if the repository is remote (step 4)or local = (step 3) and the t of vc-cvs-stay-local prevents VC from doing a full "cvs = status"-call... But obviously in some cases this combination return no state even if the = file is registered in CVS (step 4).... `vc-state' returns always a valid heuristic state if a file is under CVS = and never nil (regardless if the rep. is local or remote)... Well, Stefan said, vc-recompute-state is not for external usage - so my = question: is that behavior ok, and would irt be possible to change it, so = vc-recompute-state also returns always a valid state iuf a file is under CVS-control and = never nil?! Thanks for your efforts, Klaus Andre Spiegel wrote: > On Wed, 2004-11-24 at 09:39 +0100, klaus.berndl@sdm.de wrote: >=20 >> 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=20 >> 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...)?? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.