[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: Mon, 10 May 2004 16:46:32 -0700

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
  Checking in module/path/foo;

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?

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


reply via email to

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