[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: vc-state always calls heuristic function

From: Andre Spiegel
Subject: RE: vc-state always calls heuristic function
Date: Wed, 24 Nov 2004 11:55:00 +0100

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.

reply via email to

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