Re: Problem with timezone change in the log output

[Derek Robert Price]

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

Thomas Singer wrote:

> 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?

Yes.  A new MT "date" response has been added.

>> 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?

Yes, we do care about scripts/clients that parse CVS output, which is
why we avoid such changes in the stable releases (1.11.x).

We also prefer development to be able to move forward without being
overly encumbered by such considerations, which is what the feature
(1.12.x) series of releases is for.  When 1.12.x becomes stable, its
output format and client/server protocol will be frozen as well and a
new feature branch created.

>>> 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
> ----------------------------

I wouldn't have a problem with a change like this.  A patch with
sanity.sh test cases would probably get lots of attention.

> 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?

That depends what you mean by serious.  I, for one, would love to see
it happen.  Useful development goes on in both trees.  Unfortunately,
I don't have the time to make a concerted effort at the moment and I
haven't seen many patch submissions (I will be getting to the edit -c
patch shortly).  Without funding or more patch submissions, the merge
probably won't be happening quickly.

Cheers,

Derek
- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBCUTTLD1OTBfyMaQRAtIjAKCb3hyjNasjcnFyDVCCG+21sprcVgCffsec
aV/khM+3Hw/yB4jriQoUjeE=
=YvLY
-----END PGP SIGNATURE-----