Re: commit output

[Derek Robert Price]

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

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.

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

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

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

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

If some expect script is parsing the text messages _coming out of the
client_, it is possible that these changes could confuse that script.

Derek
- --
                *8^)

Email: derek@ximbiot.com

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

iD8DBQFAoCrmLD1OTBfyMaQRAujmAKCErp7i8ReMRcT1PLOrzAvqKWDECACdH0n+
a2NXNPsNZfjN3BEU3qP4aek=
=Wicj
-----END PGP SIGNATURE-----