> I'm seeing a few SvnAnt test failures on trunk using the command-line
> adapter. Not much time to deal with these ATM, but I hope someone
> else can get to'em. Here are the details (reproducible via 'ant
> 1) In r1770, an API for getting properties from a URL was add to
> svnClientAdapter. This API is now used by the <propget> command. The
> API's implementation is currently incomplete for the command-line
> adapter -- it passes null for the File argument to CmdLineProperty's
> constructor, which causes a NPE within that constructor:
> Testcase: testProp took 2.687 sec
> Caused an ERROR
> at org.tigris.subversion.svnant.Propget.execute(Propget.java:100)
> Solution: CmdLineProperty needs to be refactored to handle SVNUrls as
> well as Files, and CmdLineClientAdapter's usage of CmdLineProperty
> needs to be updated accordingly.
Was already fixed in r r2516.
> 2) While a test directory is getting created properly, the wrong
> number of files is found in it:
> Testcase: testConflictedSelector took 21.181 sec
> expected:<2> but was:<0>
> junit.framework.AssertionFailedError: expected:<2> but was:<0>
> Solution: I'm guessing that the test setup is not occurring quite as
> expected, and that something needs to occur to either add the expected
> files, or (more likely) mark them as conflicted.
It turned out that the command line adapter was not setting
#getConflictedOld() etc. status fields at all.
The <conflictedSelector> was relying on that.
Adapter was fixed and unite test added in r2538.
> 3) The <info /> command is getting invoked with insufficient
> arguments, which should be triggering an Ant BuildException (from
> Testcase: testSvnInfo took 0.746 sec
> Should throw BuildException because: Dir or file must be set.
> junit.framework.AssertionFailedError: Should throw BuildException
> because: Dir or file must be set.
> Solution: Either we're not triggering the BuildException like we
> should be, or we're not correctly detecting it. Figure out which is
> the problem and fix it.
This one was probably my mistake, somehow during recent refactorings the
call to validateAttributes() was lost.
It was fixed in r2536 (during addition of "failonerror").
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 24 16:04:32 2006