[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] cmdline client adapter incorrectly treats stderr as hard error

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-10-13 02:00:22 CEST

[Now with patch attached.]

On Wed, 12 Oct 2005, Daniel Rall wrote:

> On Wed, 12 Oct 2005, Daniel Rall wrote:
>
> > This first SvnAnt test failure is caused by svnClientAdapter (for <add>).
> >
> > Add.java attempts to get status for the file it plans to add, to assure that
> > the file isn't already a versioned resource:
> >
> > if (SVNStatusUtils.isManaged(svnClient.getSingleStatus(file)))
> > return;
> >
> > CmdLineClientAdapter.java calls info() and status() in succession:
> >
> > try {
> > String cmdLineInfoStrings = _cmd.info(paths); <=== EXCEPTION
> > String cmdLineStatusStrings = _cmd.status(paths, false, true, false);
> > ...
> > } catch (CmdLineException e) {
> > throw SVNClientException.wrapException(e);
> > }
> >
> > info() triggers an exception when called on an unversioned resource, because
> > it writes the warning "filename: (Not a versioned resource)" to stderr with
> > Subversion 1.4-dev (trunk). This is caused by CommandLine.execString(). I
> > believe the same behavior exists in the upcoming Subversion 1.3.
> >
> > I've attached a patch which supresses this exception in SvnAnt's Add.java.
> > However, this is not the Right approach to fixing this problem -- it should
> > be handled in svnClientAdapter, which can either 1) not treat any output to
> > stderr as a fatal error, instead acting on return code (my preference, but
> > could have significant side effects), or 2) examine the exception's log
> > message to see exactly what went wrong (a non-starter in a non-English
> > environment).
>
> I've attached another patch which implements #1. However, it loses stderr,
> which I think should be reported alongside stdout using
> CommandLine.notifyFromSvnOutput(). However, there is a complication with the
> coalesceLines behavior, so I'm posting the patch for review of the general
> approach before digging in deeper to accomodate the notification. This
> general fix will likely resolve the failure of the SvnAnt <add> test, but
> ought to be considered as a general change in behavior. Note that in the
> long term, when svn is fed multiple arguments and spits out warnings for
> some and acts on others, it will eventually return an exit code for failure;
> however, this is not the current behavior (as of Subversion 1.3).
>
> After thinking on this specific test failure for a while, it seems that the
> root cause is the fact that 'svn info' is being invoked on an unversioned
> resource -- which means that the implementation of
> CmdLineClientAdapter.getStatus(File[]) and/or CmdLineStatuses() is just
> plain wrong (at least with modern versions of Subversion).

  • text/plain attachment: patch
Received on Thu Oct 13 10:00:22 2005

This is an archived mail posted to the Subclipse Dev mailing list.