[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:08:14 +0100

address@hidden wrote:
> Thanks a lot for this detailed explanation, Andre!!
> No i understand...
Typo...Must be "Now" instead of "No" ! ;-)

> 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.
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]