RE: vc-state always calls heuristic function

[klaus.berndl]

Thanks a lot for this detailed explanation, Andre!!
No i understand...

If i have understood you right - there is currently no really
acceptable way (concering performance) to display in a file-browser
icons which always reflect the real (not heuristic) state of a file,
right?

Ciao,
Klaus

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.