Re: commit output

[Mark D. Baushke]

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

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

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

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

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.

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

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

iD8DBQFAoBRY3x41pRYZE/gRAr4WAKDTj1XEkJwen0rWFq673940jKlaoACdFBBB
aNMDpDZkPQCjUs7d4ZC4Kb8=
=JQsW
-----END PGP SIGNATURE-----