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).
- Dan
Received on Thu Oct 13 09:16:54 2005