Hi Mauro, http://bugzilla.mkgnu.net/show_bug.cgi?id=1521
On Fri, 2011-02-25 at 12:03 +0100, Mauro Molinari wrote: > Hello, > I'm here again to experiment with Scmbug. > > My problem is this: the log is too much verbose. I mean, since I'm not > interested in Scmbug to monitor branching and tagging, I set the Logging and branching are two independent things currently. > However, whenever I tag something in the CVS I receive from the CVS a > lot of the following messages (one per file, I suppose): > > Scmbug notice: --------------------------------------------------------- > Scmbug notice: Preparing for TAGGING > Scmbug notice: Processing activity > Scmbug notice: Submitting request > Scmbug notice: Request submission was accepted It is important to know what's going on in the glue. The above messages are necessary. > This considerably slows down the tagging process (in certain cases we > noticed that the time needed to tag our code base has doubled!). So I The tagging process is slowed down primarily by CVS triggering a separate tagging hook for every single directory, rather than a tagging hook just once. This is a limitation of CVS. Removing some logging would help to some extend. I am curious whether redirecting the output of the logging operation to a file may help at this stage, since logging goes through a lot of layers until it reaches your terminal. > thought about lowering the log verbosity of the glue, thinking that > those messages were at INFO level: however, looking at the configuration > file and the glue code, I discovered that the default log level is > already set to WARN and that those messages are actually logged as warnings. Yes, those messages are important. > So, my question is: shouldn't the normal "request, processing, accepted" > operations be logged as INFO, instead of WARNs? Otherwise, shouldn't the No. They should be a level above INFOs. > denied commits be logged as ERRORs? Yes, and they are. The message you noted: ./Connection.pm:353: $logger->warn( "Request submission was $response" ); ... is a WARN. And in the subsequent lines of code the response is decoded and a user-friendly message is reported as an ERROR. The other WARN you noticed is a WARN, even if the variable name reads "error_xxxx". This can be confusing to someone reviewing the code, so it is now renamed. ./Common.pm:522: $logger->warn( $error_string ); Again, I believe what you are interested in is lifting the limitation of CVS. It may be possible to do so, by implementing functionality similar to cvs_consolidate_messages. e.g. if the first tag command figures out all directories that may be involved, tags on the first one, and is completely silent on all others.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
