Quick local CVS change scan, and bug in read?

Quick local CVS change scan, and bug in read?

[Bart Schaefer]

I found a couple of hosts where I had CVS checkouts of zsh, where it
is now impossible to use e.g. "cvs diff" or "cvs status" to discover
whether there are any local changes.  So I whipped up the function
below to compare the date stamps on the individual files to the date
recorded for each in CVS/Entries.  I thought some of you might find it
useful.  (One of the few things I'm finding annoying about git is that
a cloned repository doesn't preserve file timestamps.)

In the course of testing/refining this, I discovered that some
CVS/Entries files end with the line "D" with none of the usual
field-separator slashes.  When the "while IFS=/ read ..." loop
encounters such a line, it assigns type=D but leaves name, version,
date, flags, and branch set to their existing values from the previous
loop pass.  I'm pretty sure this is wrong; bash read assigns empty
string to all the "unused" variables in the list.  I had to change
from testing for an empty $date to testing for $type not "D".

Another problem is that the %e format in strftime is supposed to
prefix single-digit dates with a space, but zstat doesn't consistently
do that, which makes the date comparison more difficult than
necessary.  For example, the leading space is present on CentOS 5 for
zsh 4.2.6 and MacOS Lion zsh version 4.3.11, but is missing on Ubuntu
10.04 zsh 4.3.10.  It's also present in a fresh build of
zsh-5.0.2-88-gaa7467b on Unbutu, so I presume this to be some kind of
strange build-specific issue.

compareCVS () {
  emulate -L zsh
  setopt extendedglob
  zmodload -i zsh/stat
  for directory in **/*~(*/)#CVS*(D/)
  do
    (
      cd $directory && if [[ -r CVS/Entries ]]
      then
        while IFS=/ read type name version date flags branch
        do
          if [[ $type != D ]]
          then
            builtin stat -A argv -gF '%a %b %e %T %Y' +mtime $name
            [[ "${date/  / }" != "${1/  / }" ]] && print
$directory/$name ${branch:+"on branch"} ${branch#T} differs
          fi
        done < CVS/Entries
      else
        print $directory NOT IN CVS
      fi
    )
  done
}

Re: Quick local CVS change scan, and bug in read?

[Phil Pennock]

On 2013-05-18 at 16:24 -0700, Bart Schaefer wrote:
> useful.  (One of the few things I'm finding annoying about git is that
> a cloned repository doesn't preserve file timestamps.)

There's a post-checkout hook in one of the answers on
<http://stackoverflow.com/questions/1964470/whats-the-equivalent-of-use-commit-times-for-git>
which might help?

> Another problem is that the %e format in strftime is supposed to
> prefix single-digit dates with a space, but zstat doesn't consistently
> do that, which makes the date comparison more difficult than
> necessary.  For example, the leading space is present on CentOS 5 for
> zsh 4.2.6 and MacOS Lion zsh version 4.3.11, but is missing on Ubuntu
> 10.04 zsh 4.3.10.  It's also present in a fresh build of
> zsh-5.0.2-88-gaa7467b on Unbutu, so I presume this to be some kind of
> strange build-specific issue.

stattimeprint() uses ztrftime() and so should be portable across OSes;
%e is implemented by zsh logic and is very explicit in handling
%providing the space unless you used %-e.

I can see that on *old* builds it would fail; when %-<foo> support was
added in 535afe3b by pws on 2009-Mar-02 [26614 + 26615] it looks like it
made %e always strip the space; then in 506c845b on 2009-Jun-26 it was
fixed with 27057:

+       * Greg Klanderman: 27057: Src/utils.c: %e and %f time formats
+       were swapped.

4.3.10 was 2009-06-01.  4.3.9 was in 2008.  4.3.11 in 2010.

So the only release cut with this bug was 4.3.10.

That seems to match your observations?

-Phil

Re: Quick local CVS change scan, and bug in read?

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Saturday, May 18, 2013, Phil Pennock wrote:

> On 2013-05-18 at 16:24 -0700, Bart Schaefer wrote:
> > (One of the few things I'm finding annoying about git is that
> > a cloned repository doesn't preserve file timestamps.)
>
> There's a post-checkout hook in one of the answers on
> <
> http://stackoverflow.com/questions/1964470/whats-the-equivalent-of-use-commit-times-for-git
> >
> which might help?


Thanks.  Based on the discussion there, AIUI the hook sets the timestamp to
the commit time?


> So the only release cut with [the strftime] bug was 4.3.10.
>
> That seems to match your observations?
>

Indeed it does, thanks for the archeology.

Re: Quick local CVS change scan, and bug in read?

[Phil Pennock]

On 2013-05-18 at 21:26 -0700, Bart Schaefer wrote:
> Thanks.  Based on the discussion there, AIUI the hook sets the timestamp to
> the commit time?

Short version: yes, with some hand-waving to cover "what you meant" vs
"pedantic".

"git help show" and in "PRETTY FORMATS" the "format:<string>" section;
%ai/%at are the author timestamp; there's two timestamps, author and
committer, each of which can be overriden by env variables
($GIT_AUTHOR_DATE, $GIT_COMMITTER_DATE).

"commit time" changes if you rebase and is used for finding when
something happened in a particular branch's history.  "author time" is
when the change is recorded as having first been made.

So the patch updates the timestamps on the files to the time of the
commit which last modified those files (not the timestamps on the files
at the time that their changes were committed).

> Indeed it does, thanks for the archeology.

No problem.  "git blame" ("git annotate") is nice, and since it only has
to work locally it's blessedly fast.  (If you've ever dealt with
Perforce, you'll know how bad annotations can be ...)

-Phil