Il 26/02/2011 06:34, Kristis Makris ha scritto: >> 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.
Sure, there is an overhead caused by the fact that the hooks are called n times, one for each directory that contains files to tag, however I think that a significant impact is caused by all of those logging messages going back and forth the network layer (from the CVS client to the CVS server). > 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. From what I understand, the errors should be reported as errors, so I shouldn't lose erorr reporting when a commit gets refused. So, I will try to lower the log verbosity to ERROR and tell you the results. >> 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. Well, this is just a point of view. From mine, a WARN should be either a potential problem the user should be notified about, or a non-blocking actual problem. An INFO, instead, should be an important information that tells the user what is going on, while a DEBUG o TRACE should be information that is not so important and that is useful for debugging and tracing. So, from this point of view, Scmbug might use the INFO level for "request, processing, accepted" notification and set INFO as the default verbosity if this is considered to be important for the user. Anyway, in practice, that's just a matter of taste. The important thing is that errors are correctly logged as ERRORs, and that's the only really crucial thing to me, so I will try to lower the verbosity and see how it goes. >> 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. Great! Thank you for your explanation. > 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. Thank you! > 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. Yes, that would be the perfect solution, however I know it's not an easy solution... I also know that we should better migrate to SVN all of our production repositories, but it's not so straight... :-( -- Mauro Molinari Software Designer & Developer E-mail: [email protected] _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
