* Quick local CVS change scan, and bug in read?
@ 2013-05-18 23:24 Bart Schaefer
2013-05-19 1:29 ` Phil Pennock
0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2013-05-18 23:24 UTC (permalink / raw)
To: Zsh hackers list
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
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Quick local CVS change scan, and bug in read?
2013-05-18 23:24 Quick local CVS change scan, and bug in read? Bart Schaefer
@ 2013-05-19 1:29 ` Phil Pennock
2013-05-19 4:26 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Phil Pennock @ 2013-05-19 1:29 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Quick local CVS change scan, and bug in read?
2013-05-19 1:29 ` Phil Pennock
@ 2013-05-19 4:26 ` Bart Schaefer
2013-05-19 5:36 ` Phil Pennock
0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2013-05-19 4:26 UTC (permalink / raw)
To: Zsh hackers list
[-- 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Quick local CVS change scan, and bug in read?
2013-05-19 4:26 ` Bart Schaefer
@ 2013-05-19 5:36 ` Phil Pennock
0 siblings, 0 replies; 4+ messages in thread
From: Phil Pennock @ 2013-05-19 5:36 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-05-19 5:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-18 23:24 Quick local CVS change scan, and bug in read? Bart Schaefer
2013-05-19 1:29 ` Phil Pennock
2013-05-19 4:26 ` Bart Schaefer
2013-05-19 5:36 ` Phil Pennock
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).