skipCommand is just a helper method to indicate which commands to not log.
You would need that even if you had a verbosity level.
Cédric Chabanois <cchabanois@no-log.org> wrote on 02/15/2005 04:26:06 PM:
> This is ok for me but I would prefer a single property verbosity instead
> of logEnabled and skipCommand.
>
> Cédric
>
> >How would you change it? Are you proposing some kind of preference?
> >
> >This is how I have currently implemented this. Not committed. I think
it
> >is similar to what you were thinking.
> >
> >
> >
> >
> >Index:
> >main/org/tigris/subversion/svnclientadapter/SVNNotificationHandler.java
> >===================================================================
> >---
> >main/org/tigris/subversion/svnclientadapter/SVNNotificationHandler.java
> >(revision 1243)
> >+++
> >main/org/tigris/subversion/svnclientadapter/SVNNotificationHandler.java
> >(working copy)
> >@@ -108,7 +108,7 @@
> > * @param commandLine
> > */
> > public void logCommandLine(String commandLine) {
> >- if (logEnabled) {
> >+ if (logEnabled && !skipCommand()) {
> > for(Iterator it=notifylisteners.iterator(); it.hasNext();)
{
> > ISVNNotifyListener listener =
> >(ISVNNotifyListener)it.next();
> > listener.logCommandLine(commandLine);
> >@@ -186,4 +186,21 @@
> > }
> > }
> >
> >+ /**
> >+ * For certain commands we just want to skip the logging of the
> >+ * command line
> >+ */
> >+ private boolean skipCommand() {
> >+ if (command == ISVNNotifyListener.Command.CAT ||
> >+ command == ISVNNotifyListener.Command.INFO ||
> >+ command == ISVNNotifyListener.Command.LOG ||
> >+ command == ISVNNotifyListener.Command.LS ||
> >+ command == ISVNNotifyListener.Command.PROPGET ||
> >+ command == ISVNNotifyListener.Command.PROPLIST ||
> >+ command == ISVNNotifyListener.Command.STATUS )
> >+ return true;
> >+ else
> >+ return false;
> >+ }
> >+
> > }
> >
> >
> >Cédric Chabanois <cchabanois@no-log.org> wrote on 02/15/2005 04:05:42
PM:
> >
> >
> >
> >>There is already a "logEnabled" property on SVNNoticationHandler.
> >>We should replace it by a verbosity level with something like
> >>LOG_NOTHING => no log
> >>LOG_QUIET => no log for propget and status ... (using command to know
> >>which command is being logged)
> >>LOG_ALL => log all
> >>
> >>And we should set verbosity to LOG_QUIET by default
> >>
> >>Cédric
> >>
> >>
> >>
> >>>Like I think most Subclipse users, I like to show the SVN Console so
> >>>
> >>>
> >that
> >
> >
> >>>I can see what I am doing. As such, I would like to modify the
client
> >>>adapter code to remove some of the messages that are just noise. The
> >>>
> >>>
> >ones
> >
> >
> >>>that immediately come to mind are propget and status. But I think
the
> >>>general rule should be any message that does not provide additional
> >>>
> >>>
> >output
> >
> >
> >>>that could be useful. So for example, the message for "update" is
> >>>
> >>>
> >useful
> >
> >
> >>>because it is always followed by some "response message" from
> >>>
> >>>
> >Subversion.
> >
> >
> >>>Ideally, we would have had some kind of priority framework on
messages
> >>>(Info, Debug etc..) and we could control what level we see in the
> >>>preferences. However, that would be a highly disruptive change at
this
> >>>
> >>>
> >
> >
> >
> >>>point and would not really provide that much benefit.
> >>>
> >>>I will hold off on making any changes before I get feedback, but
again
> >>>
> >>>
> >my
> >
> >
> >>>proposal is just to change propget and status to not log their
commands
> >>>
> >>>
> >to
> >
> >
> >>>the console, and I would be willing to do some others at the same
time
> >>>
> >>>
> >if
> >
> >
> >>>anyone wants to propose any additional commands.
> >>>
> >>>Thanks
> >>>
> >>>
> >>>
> >>>
> >>>
>
>>_____________________________________________________________________________
> >>
> >>
> >>>Scanned for SoftLanding Systems, Inc. by IBM Email Security
Management
> >>>
> >>>
> >>Services powered by MessageLabs.
> >>
>
>>_____________________________________________________________________________
> >>
> >>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> >>>For additional commands, e-mail: dev-help@subclipse.tigris.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> >>For additional commands, e-mail: dev-help@subclipse.tigris.org
> >>
> >>
> >>
> >>
> >>
>
>_____________________________________________________________________________
> >
> >
> >>Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
> >>Services powered by MessageLabs.
> >>
> >>
> >>
>
>_____________________________________________________________________________
> >
> >
>
>_____________________________________________________________________________
> >Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
> Services powered by MessageLabs.
>
>_____________________________________________________________________________
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> >For additional commands, e-mail: dev-help@subclipse.tigris.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
>
_____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
> Services powered by MessageLabs.
>
_____________________________________________________________________________
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Feb 16 08:35:14 2005