[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
behavior of vc-recompute-state in combination with vc-cvs-stay-local is
behavior of vc-recompute-state in combination with vc-cvs-stay-local is t
Mon, 29 Nov 2004 17:31:27 +0100
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))
(cd (file-name-directory file))
(vc-do-command t 0 "cvs" file "status")
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
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
nil (regardless if the rep. is local or remote)...
Well, Stefan said, vc-recompute-state is not for external usage - so my
is that behavior ok, and would irt be possible to change it, so
also returns always a valid state iuf a file is under CVS-control and never
Thanks for your efforts,
Andre Spiegel wrote:
> On Wed, 2004-11-24 at 09:39 +0100, address@hidden 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.
- behavior of vc-recompute-state in combination with vc-cvs-stay-local is t,