Re: cvs2cl: --utc --accum keeps including old changes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Could you please send me a small chunk of cvs log (i.e., simply redirect
> the output of cvs log to a file), that demonstrates this bug. Then I
> might be able to look into it.

Sure.

% cvs -d :pserver:anonymous@tiefighter.et.tudelft.nl:2401/arthur co cvsd
cvs checkout: Updating cvsd
U cvsd/.cvsignore
U cvsd/AUTHORS
U cvsd/COPYING
U cvsd/ChangeLog
U cvsd/ChangeLog-2001
U cvsd/ChangeLog-2002
[snip]
U cvsd/debian/postrm
U cvsd/debian/rules
U cvsd/debian/templates
% cd cvsd
% rm ChangeLog
% touch ChangeLog
% cvs2cl --accum --utc
cvs server: Logging .
cvs server: Logging debian
% cp ChangeLog{,.ORIG}
% cvs2cl --accum --utc
cvs log: Logging .
cvs log: Logging debian
% diff ChangeLog.ORIG ChangeLog
14a15,23
> 2003-04-12 14:37 arthur
>
> * cvsd.conf.5.in: moved comment about problems with IPv6 listen
> options (now in FAQ) and added some Listen examples
>
> 2003-04-12 13:56 arthur
>
> * cvsd.c: change comment some something more correct
>
% cvs log > LOG
cvs server: Logging .
cvs server: Logging debian
(LOG.gz attached)
% date
Sat Apr 12 22:16:48 CEST 2003
% date -u
Sat Apr 12 20:16:50 UTC 2003

I tried it fist on a repository that didn't have any files in them that I
modified today and that didn't show the problem. The problem may come from
the time check since I noticed that the double entries all are within an
hour.

After going over the perl script I think the problem is in
maybe_grab_accumulation_date() where the retrieved date/time is not
converted from utc to the local timezone if $UTC_Times is set. cvs seems
to use the local timezone for the -d option (although the rlog manual page
suggests otherwise).

% cvs log -d'>2003-04-12 14:39' FAQ

RCS file: /arthur/cvsd/FAQ,v
Working file: FAQ
head: 1.8
branch:
locks: strict
access list:
symbolic names:
        cvsd-0_9_17: 1.7
        cvsd-0_9_16: 1.7
        cvsd-0_9_15: 1.6
        cvsd-0_9_14: 1.4
        cvsd-0_9_13_1: 1.4
        cvsd-0_9_13: 1.4
        cvsd-0_9_12_1: 1.2
        cvsd-0_9_12: 1.2
        cvsd-0_9_11: 1.2
        cvsd-0_9_10: 1.1
        cvsd-0_9_9: 1.1
keyword substitution: kv
total revisions: 8; selected revisions: 1
description:
- ----------------------------
revision 1.8
date: 2003/04/12 14:38:45; author: arthur; state: Exp; lines: +8 -0
added question about some listen options in combination with IPv6
=============================================================================

% cvs log -d'>2003-04-12 16:39' FAQ
is the first to not return the 1.8 revision log (16:38 does!).

So another option might be to use $accumulation_date (converted to utc) in
the loop when reading the output from 'cvs log' also to check if the log
messages are really the right ones.

Looking at it I think this patch fixes the problem:
% diff -Nau /usr/bin/cvs2cl cvs2cl
- --- /usr/bin/cvs2cl 2002-11-11 13:46:12.000000000 +0100
+++ cvs2cl 2003-04-12 23:10:53.000000000 +0200
@@ -223,6 +223,22 @@
   }

   close (LOG);
+
+ # convert time from utc to local timezone if the ChangeLog has
+ # dates/times in utc
+ if ($UTC_Times && $boundary_date)
+ {
+ # convert the utc time to a time value
+ my ($year,$mon,$mday,$hour,$min) = $boundary_date =~
+ m#(\d+)-(\d+)-(\d+)\s+(\d+):(\d+)#;
+ my $time = timegm(0,$min,$hour,$mday,$mon-1,$year-1900);
+ # print the timevalue in the local timezone
+ my ($ignore,$wday);
+ ($ignore,$min,$hour,$mday,$mon,$year,$wday) = localtime($time);
+ $boundary_date=sprintf ("%4u-%02u-%02u %02u:%02u",
+ $year+1900,$mon+1,$mday,$hour,$min);
+ }
+
   return $boundary_date;
 }

At least I can't reproduce the problem with this so I think it's ok ;-)

It's turned into a long email but that's what you get when you type and
test at the same time.

- -- arthur - arthur@tiefighter.et.tudelft.nl - http://tiefighter.et.tudelft.nl/~arthur --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE+mIFTVYan35+NCKcRAo5kAKC4too6YkplabXhboBjIaGZlgmFrQCbBCWe
zQa3nqgJfGiZLZEYhOHbVmU=
=vxs3
-----END PGP SIGNATURE-----