bug-cvs
[Top][All Lists]
Advanced

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

Re: Problem with timezone change in the log output


From: Thomas Singer
Subject: Re: Problem with timezone change in the log output
Date: Thu, 29 Jul 2004 20:28:21 +0200
User-agent: Thunderbird 0.7.1 (Windows/20040626)

Hi Mark,

Thank you for the feed-back.

You may wish to checkout a copy of the mainline CVS sources as there has
been a patch to the 'cvs log' and 'cvs ls' code since 1.12.9 was released

SmartCVS is a CVS client itself (does not use cvs.exe), so the patch does not help :)

The time is sent via output_tagged with a "date" tag in UTC.

Do you mean the MT response?

btw: Time is being output in ISO 8601 format "2004-07-29 09:00:00 -0700"
or "2004-07-29 16:00:00 +0000" instead of "2004/07/29 16:00:00" so you
may need to deal with paring dates with a timezone if you are not
already doing it in SmartCVS.

Yes, I will need to do it in SmartCVS. The problem is, that such changes at server side always make parsing stop working. Don't CVS server developers care much/enough about applications which (need to) parse the output of some CVS commands?

BTW, I very much would appreciate, if the CVS could produce
fully-parsable log output, e.g. by escaping special characters in the
commit messages.

I am not exactly sure what you mean. If you have suggestions that you
can express in terms of a patch to the cvs sources with tests to be
added to sanity.sh, they might be adopted.

The problem is, that the CVS *server* tries to create human readable output, which is relatively hard to parse exactly by a machine (and sometimes impossible). IMHO it would be very nice, if the CVS server could produce machine parsable output, which then will be translated to human readable output by the CVS client (including command line CVS). With "escaping special characters" I mean, that the commit messages in the log-output contain, for example, "\n" for carriage returns (instead of splitting it into multiple M responses), so the parser cannot be confused by (stupid) commit messages like this:

revision 1.68
date: 2004/07/27 18:49:23; author: tom; state: Exp; lines: +1 -0; kopt: o;
no message
----------------------------
revision 1.67
date: 2004/07/17 13:20:21; author: tom; state: Exp; lines: +1 -0; kopt: o;
no message
----------------------------


BTW, are there any serious (!) plans to merge with CVSNT, so CVS client developers like me don't have to write work-arounds for different CVS servers?

--
Best regards,
Thomas Singer
_____________
smartcvs.com



Mark D. Baushke schrieb:

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

Thomas Singer <address@hidden> writes:


My name is Thomas Singer and I'm the core developer of SmartCVS.

A user reported me, that parsing the output of the log command does
not work correctly with GNU CVS >= 1.12.9. I know, there are always
user requests (at least in the CVSNT mailing list) to show all dates
in local timezone. But I don't fully understand, why the CVS *server*
should report the date in local timezone (which needs to be told the
CVS server before). The conversion from UTC to the local timezone can
be handled very easily at client side.


You may wish to checkout a copy of the mainline CVS sources as there has
been a patch to the 'cvs log' and 'cvs ls' code since 1.12.9 was released:

| * Thanks again to Bart Robinson <address@hidden>, `cvs log' & `cvs
|   ls' now actually output local times when the server is version 1.12.9
|   or greater and the client is version 1.12.10 or greater.

The time is sent via output_tagged with a "date" tag in UTC. It is up to
the client to convert it locally which is done correctly in 1.12.9.1 and
will be visible in 1.12.10 at such time as that version is released.

btw: Time is being output in ISO 8601 format "2004-07-29 09:00:00 -0700"
or "2004-07-29 16:00:00 +0000" instead of "2004/07/29 16:00:00" so you
may need to deal with paring dates with a timezone if you are not
already doing it in SmartCVS.


BTW, I very much would appreciate, if the CVS could produce
fully-parsable log output, e.g. by escaping special characters in the
commit messages.


I am not exactly sure what you mean. If you have suggestions that you
can express in terms of a patch to the cvs sources with tests to be
added to sanity.sh, they might be adopted.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBCSAx3x41pRYZE/gRApdUAKCSANIq/cum5LEpI/30jRFc0OTclACgmY2G
NZsBn084FVNwXnArfcHoX3k=
=EO6+
-----END PGP SIGNATURE-----







reply via email to

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