[Top][All Lists]

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

bug#7905: 24.0.50; VC not updating file status properly anymore after co

From: Tim Van Holder
Subject: bug#7905: 24.0.50; VC not updating file status properly anymore after commit from vc-dir
Date: Thu, 27 Jan 2011 10:51:37 +0100

On 27 January 2011 08:25, Glenn Morris <address@hidden> wrote:
> Tim Van Holder wrote:
>>> Would it help for me to edebug particular VC defuns to see where
>>> exactly things go wrong?
>> It seems to run deeper than just commits. I'm seeing now that any
>> CVS-controlled file I visit is marked as "CVS:1.x" (i.e. edited), even
>> files in a freshly checked out sandbox. [C-x v u] clears that state,
>> but saving the file, closing it and then revisiting it puts it in
>> edited state again.
> Well that is all very wacky. Does eg Emacs 23.2 work right on that
> system at present with CVS? (This is a Cygwin build?)

I've been running from CVS HEAD (and now bzr trunk) for years now; the
latest "installed" version is (an old CVS HEAD build).
A commit from [C-x v d] there has the "(added)" tag correctly
disappearing, but it's still the old VC (vc-dired-mode instead of
vc-dir), so I'm not sure it matters much.
Main problem with the system is that the hardware has no kernel
support anymore, so I cannot deploy official packages anymore (they
all require a kernel upgrade); if absolutely necessary I could build
23.2 from sources to test its behaviour.

It's not a cygwin build by the way - it's a debian linux build, but
I'm running it from a PuTTY session on Windows, which then tunnels the
X connection to the cygwin X windows.
It's definitely an exotic setup (there are some serious problems with
the recent changes to the clipboard handling), but I don't think
that's likely to affect VC (the sandboxes are all on the linux
machine's file system, not on a samba share).

> You could try edebugging vc-cvs-state, vc-cvs-state-heuristic, and
> vc-cvs-parse-entry. And the vc-cvs-*-dir-* functions if you want to
> check vc-dir behaviour.

Think I see the problem being caused by vc-cvs-state-heuristic; it
uses the file's checkout property:
  (vc-file-getprop file 'vc-checkout-time)
But this seems to always return 0 when I try to open a CVS-controlled
file, which means vc-cvs-state-heuristic will only report either
'added or 'edited.

reply via email to

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