AW: behavior of vc-recompute-state in combination withvc-cvs-stay-local is t

[klaus.berndl]

On Mon, 2004-11-29 at 17:31 +0100, address@hidden wrote:

>> 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.

>The code was simply based on the assumption that vc-recompute-state
>would only be called for files that are already visited.  In this case,
>vc-state can never be nil because we compute it at visiting time
>already.

ah, i had already a suspicion like that....
But what i still do not understand, why vc-recompute-state behaves
different related if the repository is local or remote 8at least this
is the only difference i can imagine between the two testcases - see
my first postin, steps 4 and 3?

>I've changed this now and moved vc-recompute-state into vc-hooks.el.  It
>should always return a valid state now.

ah, this sounds wonderful! IMHO this would be a very good enhencement
for tools like ECB which want to display a VC-state also for file
not already visited... Thanks, Andre!

May i ask another problem/question related to `vc-state'? Please see
the following very simple and fast testable scenario:

1. load a file (lets say the filename is XXX.txt) into Emacs, which is
   under control of CVS
2. do some editing changes and save it - do not kill the buffer
3. M-: (vc-state "XXX.txt") RET ==> return 'edited for me
4. No checkin this file but not from within Emacs, so e.g. via bash command line
5. M-: (vc-state "XXX.txt") RET ==> returns again 'edited
   (but currently 'up-to-date would be correct)
6. Call M-x revert-buffer
7. Again M-: (vc-state "XXX.txt") RET ==> Now vc-state returns the correct
   'up-to-date state

So, which mysterious things are done by revert-buffer so *after* it vc-state returns
correct 'up-to-date state but wrong 'edited state if called *before* the
revert-buffer???

Thanks again,
Klaus