Re: [Subclipse-dev] svnant maintainer

Frank,

I'm the one who posted one of those patches (#665) originally. Please
feel free to contact me if you have any questions about my tickets. It's
nice to see someone pick up svnant.

-- 
Maciek Sakrejda
Truviso, Inc.
http://www.truviso.com
-----Original Message-----
From: Mark Phippard <markphip_at_gmail.com>
Reply-To: dev_at_subclipse.tigris.org
To: dev_at_subclipse.tigris.org
Subject: Re: [Subclipse-dev] svnant maintainer
Date: Tue, 12 Aug 2008 14:26:37 -0400
On Mon, Aug 11, 2008 at 1:06 AM, Joshua Frankamp <frankamp_at_gmail.com> wrote:
> The second issue is that not all the tests passed. Is it acceptable to
> commit against the svnant trunk even though not all the tests pass, as
> long as they aren't originating or properly fixable from svnant?
What tests are these?  svnClientAdapter or svnAnt?  The former have
not been maintained in a while (check the history).  Not that they
should not still work.
> SvnJavaHLTest Tests run: 50, Failures: 1, Errors: 1
>
> testProp fails:
> Propset munges input file, propget works fine. Reproducable in
> subclipse also with javaHL as the backing library. Turns a 170 byte
> gif into a 275 byte (thrashed) gif. Specifically expands the null byte
> into two other boundary bytes among other things.
This would likely be a bug in Subversion (having not seen the test).
For the most part, our code does not touch anything on disk.  We just
call API's.  If we are passing the filename to an API it would be a
Subversion bug.  If we read the bytes ourselves, then maybe it is a
bug on our end.  I know that our code in this area has not changed in
years though.
> testInfo errors:
> File info request based on url produces NPE in JhlInfo2, patch in
> svnClientAdapter waiting should fix it, see
> http://subclipse.tigris.org/issues/show_bug.cgi?id=665
Feel free to commit a fix.
> SvnSvnKitTest Tests run: 50, Failures: 2, Errors: 1
>
> testSvnExists fails:
> I traced it to past AbstractJhlClientAdapter getInfo(File f) in
> svnClientAdapter. The svnClient.info request produces the correct
> revision but the secondary info2 produces rev:-1 and so incorrectly
> produces a "not version controlled" for svnExists. A manual command
> line test in this same working copy produces the correct revision.
>
> testConflictedSelector fails:
> I traced this to JhlStatus.getConflictWorking in svnClientAdapter, it
> appears that svnkit is returning empty string for a "there is no
> conflicted working file" response instead of null. JhlStatus checks
> for nullity, and decides to return the parent of the file. The parent
> of the file is then not null, which means the conflicted selector
> selects everything.
>
> testInfo errors: see above
SVNKit pretty much works (in our products) by emulating JavaHL.  We
even just use the same JavaHL adapter code for 95% of it.  So might be
worth emailing support_at_svnkit.com with whatever info you can give
them.  Of course this is only in cases where the same test works for
JavaHL.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org