behavior of vc-recompute-state in combination with vc-cvs-stay-local is t

behavior of vc-recompute-state in combination with vc-cvs-stay-local is t

[klaus.berndl]

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")
   ==> returns a valid state (e.g. up-to-date)
4. Running (vc-recompute-state "/a/file/under/remote-repository-CVS/file.txt")
   ==> 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:
> 
>> 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.

Re: behavior of vc-recompute-state in combination with vc-cvs-stay-local is t

[Andre Spiegel]

On Mon, 2004-11-29 at 17:31 +0100, klaus.berndl@sdm.de wrote:

> 4. Running (vc-recompute-state "/a/file/under/remote-repository-CVS/file.txt")
>    ==> returns always nil, because the state-binding in the vc-cvs-state is
>        always nil for that file.

The code was simply based on the assumption that vc-recompute-state
would only be called for files that are already visited.  In this case,
vc-state can never be nil because we compute it at visiting time
already.

I've changed this now and moved vc-recompute-state into vc-hooks.el.  It
should always return a valid state now.