[Top][All Lists]

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

Re: commit output

From: Derek Robert Price
Subject: Re: commit output
Date: Mon, 10 May 2004 21:22:47 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413

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

> 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

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

- --

Email: derek@ximbiot.com

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


reply via email to

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