[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: vc-state always calls heuristic function
From: |
klaus.berndl |
Subject: |
RE: vc-state always calls heuristic function |
Date: |
Wed, 24 Nov 2004 12:04:23 +0100 |
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.
- vc-state always calls heuristic function, klaus.berndl, 2004/11/23
- RE: vc-state always calls heuristic function, klaus.berndl, 2004/11/23
- RE: vc-state always calls heuristic function, klaus.berndl, 2004/11/24
- RE: vc-state always calls heuristic function,
klaus.berndl <=
- RE: vc-state always calls heuristic function, klaus.berndl, 2004/11/24
- RE: vc-state always calls heuristic function, klaus.berndl, 2004/11/24
- RE: vc-state always calls heuristic function, klaus.berndl, 2004/11/24