[Top][All Lists]

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

Re: commit output

From: Mark D. Baushke
Subject: Re: commit output
Date: Tue, 11 May 2004 08:26:25 -0700

Hash: SHA1

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> > >Yes, many messages are generated on the server and no, actual
> > >"clients" attempting to parse the output of the server should not have
> > >problems with the changes since the CVS client/server protocol is
> > >rather sharply defined in such a way that merely altering some of the
> > >messages destined for user consumption should not alter the client
> > >interpretation.
> >
> > I know that some of the additions of "`" and "'" or otherwise altering
> > what punctuation were around which files was what caused eclipse.org
> > stuff to be broken for a while. It was this kind of change to the output
> > of stable that I was trying to protect against if possible.
> Hrm.  Interesting.  I was told at some point that they had their own
> client.

This is enitrely possible. The messages that were changed came from the
server across the client/server connection. As I understood it, part of
the 'problem' in the client/server interaction is that some of the
information that is coming back to the client that might be interesting
for some clients is also carried in the printf() strings.

Consider the 'cvs diff' command. The 'diff' is actually performed on the
server. If the client/server connection sends the -u switch across,
there is no way for the client to do a context-diff after the fact or to
colorize the differences without parsing the output of the text that is
being sent to stdout.

For another example.... how about the latest patch by Bart Robinson that
deals with timezone has to make sure to go thru the cvs_output_tagged()
to handle date manipulations otherwise the client would not know where
to deal with that kind of display information.

> Anyhow, it really does make sense to leave output alone on feature, I
> guess. Time to bump the feature -> stable date. What did you suggest,
> Mark? 6 months? That's November... Seems like a long time... :)

I have no problems with making it sooner, but it would probably be best
to announce the plans so that folks with distributions that include cvs
can plan accordingly and we might actually get them to start moving to a
cvs 1.12.x distribution if we get serious about making that the stable
release as well.

> > >If some expect script is parsing the text messages _coming out of the
> > >client_, it is possible that these changes could confuse that script.
> >
> >
> > Sure, for example, there is the need to hack the sanity.sh regression
> > tests...
> Well, yes, but that gets committed with these sorts of changes, in
> general.  :)


        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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