Re: commit output

[Mark D. Baushke]

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

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

> Mark D. Baushke wrote:
> 
> > Derek Robert Price <derek@ximbiot.com> writes:
> >
> > >Actually, there were two questions.  One was for some -q/-Q changes
> > >for stable and the other was for the same for feature, but also
> > >removing pretty much every message that went away with the -q on
> > >stable, permanently, regardless of the specified verbosity level.
> >
> >
> > I have no objections to removal of
> >
> >   RCS file: .*,v
> >   done
> >   Checking in module/path/foo;
> >   done
> 
> 
> This was exactly what I was trying to get at, for feature.

Okay.

> > I would like to keep the 'cvs comit: Examining module/path' style
> > messages as well as keeping the messages like:
> >
> >   '$CVSROOT_DIRNAME/module/dir/path/file,v  <-- file'
> >
> > as well as all of the variations on
> >
> > 'initial revision: 1.1'
> > 'new revision: 1.2; previous revision: 1.1'
> > 'new revision: delete; previous revision: 3.1'
> >
> > for cvs commit operations. I would also like to keep the various
> 
> 
> These are exactly the messages I proposed to leave alone, though they
> would vanish for -Q, since -Q is defined to " only generate output for
> serious problems" in the manual.

Right.

> > 'T directory/file'
> >
> > output lines for cvs tag output and the messages like
> >
> > 'deleting revision 1.1'
> >
> > that is geneated from commands like 'cvs admin -o1.1'
> 
> 
> I wasn't planning on touching anything but the commit messages at this
> time.

Okay.

> > Under the -Q switch, that output may be surpessed. I am less certain
> > what makes the most sense in all cases for the -q switch.
> 
> 
> -q suppression can sometimes be worthy of discussion, but on feature,
> in this case, I would only be removing some redundant messages and
> moving the rest int -Q suppression, for commit.

Okay.

> > >So anyhow, I mentioned in another thread that I believe Eclipse has
> > >its own CVS client.  Thus, it only relies on the stability of the
> > >client/server protocol specification and not the command line output.
> > >Is there another audience you think should be notified of a change of
> > >a commits reaction to -q?
> >
> > Nothing comes to mind in this case.
> >
> > However, are not many of those messages being generated by the server
> > and sent to the client? So, if another client is trying to parse the
> > output of the server, would alterations of those messages on the server
> > need to be controlled in some kind of backward compatible manner?
> 
> 
> 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.

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

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

iD8DBQFAoCwh3x41pRYZE/gRAtvaAJ48rWE/1FvtamgcjpWBDDdxS0KpFgCgun9w
OhjlHAEOXmXvNusT7aHRtsc=
=6Cdk
-----END PGP SIGNATURE-----