bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#7221: timestamp in cvs-quickdir on Win32 system


From: Rolf Unger
Subject: bug#7221: timestamp in cvs-quickdir on Win32 system
Date: Fri, 27 Aug 2021 01:06:56 +0200
User-agent: NeoMutt/20170113 (1.7.2)

Hi Lars,

I gave it a go with your suggested patch, and it still marks some files as
modified that are not modified.

Maybe I should give some details to my constellation:
My working directory is on a win32 machine, but the repository is on a
Linux box and I use the pserver protocol to access the repository.
My Project resides all in one directory, it consists of two .c files, a
header file and some Windows resource script files .rc. Furthermore I have
a Makefile for MinGW gnu make and one .mak file for nmake.

The Makefile, the .mak and the .rc resource files are marked as modified
if I open the project directory with `csv-quickdir`. The .c files and the
header file are not shown (the rule for files that are up-to-date)
If I use cvs-status on this same directory all files are shown as
up-to-date (which is the same what I get if I run `cvs status` in a shell.

The interesting part is: If I open a file (the Makefile for example) with
`o` in the other window the *cvs* buffer will immediately show the file
that have just opened as `modidied`. But I haven't done any changes in
that opened file, only the active cursor is in that buffer.
If I hit `g` to refresh the *cvs* buffer with (cvs -f -n update -d -P)
the opened file that is said to be modified will transition to Up-To-Date
again.
I thought it could be related with the character encoding because the .rc
files are UTF-8 encded and theser .rc files are shown as modified.
But if it is a encoding issue it should not happen for the Makefile,
because this file as ASCII clean file.

If I execute `vc-dir` on my project only some unregistered files are
shown, because vc doesn't show files that are not modified.
So `vc` does show the status of the files correctly.

All this strange behaviour let's me guess, that the problem is not within
the elisp code and maybe wrong assumptions on the date format of cvs'
timestamp of the revision.

Rolf

On Thu, 26 Aug 2021 after 20 h, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I don't think I agree.  My reading of the relevant CVS code is that
> > CVS uses either 'asctime' or 'ctime' to produce the time string for
> > "Entries", and 'asctime'/'ctime' always produce the standard format of
> > the time, not the locale-preferred format produced by %c.  See
> > vers_ts.c:time_stamp in the CVS sources.
> >
> > FWIW, I see the same problem on my MS-Windows machine.
>
> Does the proposed patch fix the issue, then?  It removes the "%c" and
> uses a more standard date format:
>
> diff --git a/lisp/vc/pcvs-info.el b/lisp/vc/pcvs-info.el
> index 9f8a168a0a..5a607e337b 100644
> --- a/lisp/vc/pcvs-info.el
> +++ b/lisp/vc/pcvs-info.el
> @@ -454,7 +454,8 @@ cvs-fileinfo-from-entries
>              ((let ((mtime (file-attribute-modification-time
>                             (file-attributes (concat dir f))))
>                     (system-time-locale "C"))
> -               (setq timestamp (format-time-string "%c" mtime t))
> +               (setq timestamp (format-time-string "%a %b %e %H:%M:%S %Y"
> +                                                      mtime t))
>                 ;; Solaris sometimes uses "Wed Sep 05", not "Wed Sep  5".
>                 ;; See "grep '[^a-z_]ctime' cvs/src/*.c" for reference.
>                 (if (= (aref timestamp 8) ?0)
>
>
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no






reply via email to

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