bug#7905: 24.0.50; VC not updating file status properly anymore after commit from vc-dir

[Tim Van Holder <tim.vanholder@gmail.com>]

On 28 January 2011 19:16, Glenn Morris <rgm@gnu.org> wrote:
> Tim Van Holder wrote:
>
>> Think I see the problem being caused by vc-cvs-state-heuristic;
>
> This doesn't make sense to me, because vc-dir supposedly never uses that.
> But if so, setting vc-cvs-stay-local to nil should make everything work.

I checked the file-is-considered-edited-on-open behaviour, and there
vc-cvs-state-heuristic seems to be the culprit; as I mentioned, vc-dir
did not consider all files as modified.
Also, vc-dir correctly identifies the state after a 'g', so vc-dir
seems to work correctly in and of itself. I'm assuming the
update-status-in-vc-dir behaviour after a commit relies on local
operations, so if it expects to run vc-cvs-state-heuristic on the
newly-committed files to get their new state, it could be the culprit
there too.

>> 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.
>
> Maybe edebugging vc-cvs-parse-entry will show why this is so.

Aha - it looks like it's a timezone thing. vc-cvs-parse-entry does
everything right, except that it tries to compare the file's mtime
with the time from CVS/Entries, assuming UTC as timezone for it (which
is correct for CVS/Entries but apparently not for mtime).
In my case, they differ by an hour:

$ date; date --utc
Mon Jan 31 09:50:50 CET 2011
Mon Jan 31 08:50:50 UTC 2011
$ grep foo CVS/Entries
/foo/1.297.2.24/Mon Jan 31 08:30:58 2011//Tmytag
$ stat foo
  File: `foo'
  Size: 75579           Blocks: 160        IO Block: 4096   regular file
Device: 808h/2056d      Inode: 8142863     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     tim)   Gid: ( 1000/     tim)
Access: 2011-01-31 09:37:57.000000000 +0100
Modify: 2011-01-31 09:30:58.000000000 +0100
Change: 2011-01-31 09:31:00.000000000 +0100

As a result, checkout-time is set to 0 (and state to edited).

Running "TZ=UTC emacs" shows the problem going away (both the vc-dir
state change and the file-edited-on-open).
So perhaps mtime needs decode-time applied, and then the zone argument
applied to the time info (I would expect there to be a function for
that already, but I didn't see one offhand).

> Perhaps the CVS/Entries file has an unexpected format.

Doubtful, since this also affected fresh clean sandboxes (like the one
in the sample).