You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marc Strapetz <ma...@syntevo.com> on 2015/08/13 13:32:44 UTC
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
On 27.07.2015 09:21, Branko Čibej wrote:
> On 27.07.2015 09:17, Marc Strapetz wrote:
>> One of our 1.9 (early-access) users is reporting problems when
>> performing remote commands, for example a copy URL->URL:
>>
>> org.apache.subversion.javahl.ClientException: Stream doesn't support
>> this capability
>> Bad file descriptor
>> svn: Polling for available data on filestream failed: Bad file descriptor
>> at org.apache.subversion.javahl.SVNClient.copy(Native Method)
>> at ...
>>
>> He hasn't encountered such problems with 1.8 versions.
>>
>> AFAIU, he is connecting using SSH. Is this an SSH-related problem?
>> Could it be related to the underlying SSH client?
>
> Which platform is this? Can the user reproduce this problem with the
> command-line svn on the same machine?
It's on Windows, in combination with SSH. I'm now able to reproduce this
problem myself and it looks like a regression to me:
It's reproducible with our own Windows binaries as well as with the
WANdisco binaries. It's reproducible with Plink/Pageant as well as with
Trilead SSH. The commit works fine with Subversion 1.8.
Is there any additional information/debugging I can do on my side?
-Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Thomas Singer <th...@syntevo.com>.
Is *anybody* of the Windows users able to commit using svn+ssh:// and
SVN 1.9?
--
Thomas
On 14.08.2015 00:20, Branko Čibej wrote:
> On 13.08.2015 13:32, Marc Strapetz wrote:
>> On 27.07.2015 09:21, Branko Čibej wrote:
>>> On 27.07.2015 09:17, Marc Strapetz wrote:
>>>> One of our 1.9 (early-access) users is reporting problems when
>>>> performing remote commands, for example a copy URL->URL:
>>>>
>>>> org.apache.subversion.javahl.ClientException: Stream doesn't support
>>>> this capability
>>>> Bad file descriptor
>>>> svn: Polling for available data on filestream failed: Bad file
>>>> descriptor
>>>> at org.apache.subversion.javahl.SVNClient.copy(Native Method)
>>>> at ...
>>>>
>>>> He hasn't encountered such problems with 1.8 versions.
>>>>
>>>> AFAIU, he is connecting using SSH. Is this an SSH-related problem?
>>>> Could it be related to the underlying SSH client?
>>>
>>> Which platform is this? Can the user reproduce this problem with the
>>> command-line svn on the same machine?
>>
>> It's on Windows, in combination with SSH. I'm now able to reproduce
>> this problem myself and it looks like a regression to me:
>>
>> It's reproducible with our own Windows binaries as well as with the
>> WANdisco binaries. It's reproducible with Plink/Pageant as well as
>> with Trilead SSH. The commit works fine with Subversion 1.8.
>>
>> Is there any additional information/debugging I can do on my side?
>
> I'd still want to know if the command-line client works. If not, a
> minimal Java program using JavaHL that demonstrates the problem would be
> a real help.
>
> -- Brane
>
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support
thiscapability" errors
Posted by Thomas Singer <th...@syntevo.com>.
> The fix is alread on the 1.9.x branch and will be
> part of the 1.9.1 release
Perfect, I can confirm that it is working now. Thanks.
--
Tom
On 25.08.2015 12:39, Branko Čibej wrote:
> On 25.08.2015 12:36, Thomas Singer wrote:
>> Is this bug already reported in the issue tracker? I've searched but
>> could not found. Should I report it?
>
>
> We don't need that. The fix is alread on the 1.9.x branch and will be
> part of the 1.9.1 release, which we'll probably expedite precisely
> because of this bug.
>
> -- Brane
>
>
>>
>> --
>> Best regards,
>> Thomas Singer
>> =============
>> syntevo GmbH
>> http://www.syntevo.com
>> http://www.syntevo.com/blog
>>
>>
>> On 20.08.2015 09:28, bert@qqmail.nl wrote:
>>> Hi Thomas,
>>>
>>> The Subversion version of the fix is nominated for 1.9.1
>>> [[
>>> + * r1696222, r1696225
>>> + Implement polling on named pipes on Windows to resolve svn+ssh://
>>> problems
>>> + Justification:
>>> + Without this patch operations like checkout just fail with an
>>> error.
>>> + This is a regression as older Subversion releases ignored the
>>> error.
>>> + Votes:
>>> ]]
>>>
>>> Apr just returns EBADF on any attempt to poll on a file or pipe on
>>> Windows. This workaround on the Subversion side makes us support
>>> polling on pipes. (In Subversion < 1.8 we always assumed that there
>>> was no data waiting, because we never bothered to check for an error)
>>>
>>> The apr version of the patch is harder than I expected, because the
>>> poll function supports many flags of which we can really only
>>> implement one new variant, that can’t really be combined with any
>>> other flags.
>>>
>>>
>>> We need one more vote on this, before we can start the release
>>> process on 1.9.1.
>>>
>>> I would hope we can also get r1696695 in the release, as that problem
>>> appears to break Subversion for at least some Linux distributions.
>>>
>>>
>>>
>>> We might want to consider also fixing the polling in 1.8 (and 1.7?),
>>> as that would allow exiting much earlier when a commit fails.
>>> Currently Subversion (when using svn+ssh:// on Windows) just goes on
>>> trying to commit on Windows and only notices that svnserve returned
>>> an error when done.
>>>
>>>
>>> Bert
>>>
>>> Sent from Mail for Windows 10
>>>
>>>
>>>
>>> From: Thomas Singer
>>> Sent: donderdag 20 augustus 2015 08:23
>>> To: dev@subversion.apache.org
>>> Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't
>>> support thiscapability" errors
>>>
>>>
>>> Hi Bert,
>>>
>>>> I'll see if I can properly fix this (preferably in both Subversion
>>>> and Apr), without reverting to just ignoring errors.
>>>
>>> Did you have any success fixing it yet? Is there already a bug entered
>>> in the issue tracker? I'd rate it as blocker priority.
>>>
>>> --
>>> Best regards,
>>> Thomas Singer
>>> =============
>>> syntevo GmbH
>>> http://www.syntevo.com
>>> http://www.syntevo.com/blog
>>>
>>>
>>>
>
>
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support
thiscapability" errors
Posted by Branko Čibej <br...@wandisco.com>.
On 25.08.2015 12:36, Thomas Singer wrote:
> Is this bug already reported in the issue tracker? I've searched but
> could not found. Should I report it?
We don't need that. The fix is alread on the 1.9.x branch and will be
part of the 1.9.1 release, which we'll probably expedite precisely
because of this bug.
-- Brane
>
> --
> Best regards,
> Thomas Singer
> =============
> syntevo GmbH
> http://www.syntevo.com
> http://www.syntevo.com/blog
>
>
> On 20.08.2015 09:28, bert@qqmail.nl wrote:
>> Hi Thomas,
>>
>> The Subversion version of the fix is nominated for 1.9.1
>> [[
>> + * r1696222, r1696225
>> + Implement polling on named pipes on Windows to resolve svn+ssh://
>> problems
>> + Justification:
>> + Without this patch operations like checkout just fail with an
>> error.
>> + This is a regression as older Subversion releases ignored the
>> error.
>> + Votes:
>> ]]
>>
>> Apr just returns EBADF on any attempt to poll on a file or pipe on
>> Windows. This workaround on the Subversion side makes us support
>> polling on pipes. (In Subversion < 1.8 we always assumed that there
>> was no data waiting, because we never bothered to check for an error)
>>
>> The apr version of the patch is harder than I expected, because the
>> poll function supports many flags of which we can really only
>> implement one new variant, that can’t really be combined with any
>> other flags.
>>
>>
>> We need one more vote on this, before we can start the release
>> process on 1.9.1.
>>
>> I would hope we can also get r1696695 in the release, as that problem
>> appears to break Subversion for at least some Linux distributions.
>>
>>
>>
>> We might want to consider also fixing the polling in 1.8 (and 1.7?),
>> as that would allow exiting much earlier when a commit fails.
>> Currently Subversion (when using svn+ssh:// on Windows) just goes on
>> trying to commit on Windows and only notices that svnserve returned
>> an error when done.
>>
>>
>> Bert
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Thomas Singer
>> Sent: donderdag 20 augustus 2015 08:23
>> To: dev@subversion.apache.org
>> Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't
>> support thiscapability" errors
>>
>>
>> Hi Bert,
>>
>>> I'll see if I can properly fix this (preferably in both Subversion
>>> and Apr), without reverting to just ignoring errors.
>>
>> Did you have any success fixing it yet? Is there already a bug entered
>> in the issue tracker? I'd rate it as blocker priority.
>>
>> --
>> Best regards,
>> Thomas Singer
>> =============
>> syntevo GmbH
>> http://www.syntevo.com
>> http://www.syntevo.com/blog
>>
>>
>>
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support
thiscapability" errors
Posted by Thomas Singer <th...@syntevo.com>.
Is this bug already reported in the issue tracker? I've searched but
could not found. Should I report it?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
On 20.08.2015 09:28, bert@qqmail.nl wrote:
> Hi Thomas,
>
> The Subversion version of the fix is nominated for 1.9.1
> [[
> + * r1696222, r1696225
> + Implement polling on named pipes on Windows to resolve svn+ssh:// problems
> + Justification:
> + Without this patch operations like checkout just fail with an error.
> + This is a regression as older Subversion releases ignored the error.
> + Votes:
> ]]
>
> Apr just returns EBADF on any attempt to poll on a file or pipe on Windows. This workaround on the Subversion side makes us support polling on pipes. (In Subversion < 1.8 we always assumed that there was no data waiting, because we never bothered to check for an error)
>
> The apr version of the patch is harder than I expected, because the poll function supports many flags of which we can really only implement one new variant, that can’t really be combined with any other flags.
>
>
> We need one more vote on this, before we can start the release process on 1.9.1.
>
> I would hope we can also get r1696695 in the release, as that problem appears to break Subversion for at least some Linux distributions.
>
>
>
> We might want to consider also fixing the polling in 1.8 (and 1.7?), as that would allow exiting much earlier when a commit fails. Currently Subversion (when using svn+ssh:// on Windows) just goes on trying to commit on Windows and only notices that svnserve returned an error when done.
>
>
> Bert
>
> Sent from Mail for Windows 10
>
>
>
> From: Thomas Singer
> Sent: donderdag 20 augustus 2015 08:23
> To: dev@subversion.apache.org
> Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support thiscapability" errors
>
>
> Hi Bert,
>
>> I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors.
>
> Did you have any success fixing it yet? Is there already a bug entered
> in the issue tracker? I'd rate it as blocker priority.
>
> --
> Best regards,
> Thomas Singer
> =============
> syntevo GmbH
> http://www.syntevo.com
> http://www.syntevo.com/blog
>
>
>
RE: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support
thiscapability" errors
Posted by be...@qqmail.nl.
Hi Thomas,
The Subversion version of the fix is nominated for 1.9.1
[[
+ * r1696222, r1696225
+ Implement polling on named pipes on Windows to resolve svn+ssh:// problems
+ Justification:
+ Without this patch operations like checkout just fail with an error.
+ This is a regression as older Subversion releases ignored the error.
+ Votes:
]]
Apr just returns EBADF on any attempt to poll on a file or pipe on Windows. This workaround on the Subversion side makes us support polling on pipes. (In Subversion < 1.8 we always assumed that there was no data waiting, because we never bothered to check for an error)
The apr version of the patch is harder than I expected, because the poll function supports many flags of which we can really only implement one new variant, that can’t really be combined with any other flags.
We need one more vote on this, before we can start the release process on 1.9.1.
I would hope we can also get r1696695 in the release, as that problem appears to break Subversion for at least some Linux distributions.
We might want to consider also fixing the polling in 1.8 (and 1.7?), as that would allow exiting much earlier when a commit fails. Currently Subversion (when using svn+ssh:// on Windows) just goes on trying to commit on Windows and only notices that svnserve returned an error when done.
Bert
Sent from Mail for Windows 10
From: Thomas Singer
Sent: donderdag 20 augustus 2015 08:23
To: dev@subversion.apache.org
Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support thiscapability" errors
Hi Bert,
> I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors.
Did you have any success fixing it yet? Is there already a bug entered
in the issue tracker? I'd rate it as blocker priority.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Thomas Singer <th...@syntevo.com>.
Hi Bert,
> I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors.
Did you have any success fixing it yet? Is there already a bug entered
in the issue tracker? I'd rate it as blocker priority.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
RE: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Marc Strapetz [mailto:marc.strapetz@syntevo.com]
> Sent: maandag 17 augustus 2015 08:58
> To: Philip Martin <ph...@wandisco.com>
> Cc: Branko Čibej <br...@wandisco.com>; dev@subversion.apache.org
> Subject: Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
> capability" errors
>
> On 14.08.2015 11:21, Philip Martin wrote:
> > Marc Strapetz <ma...@syntevo.com> writes:
> >
> >> It's reproducible with an empty repository on the server (just
> >> initialized with svnadmin) and a local repository which has been
> >> prepared for the initial import:
> >>
> >> C:\temp\svn> svn status -v
> >> 0 0 ? .
> >> A - ? ? dir
> >> A - ? ? dir\subfile
> >> A - ? ? file
> >>
> >> C:\temp\svn> svn commit -m "initial import"
> >> svn: E140004: Commit failed (details follow):
> >> svn: E140004: Stream doesn't support this capability
> >> svn: E000009: Polling for available data on filestream failed: Bad
> >> file descriptor
> >>
> >> On the server, we are running SVN 1.6.17.
> >
> > That's the apr_poll() call in data_available_handler_apr() failing, and
> > E000009 could be EBADF. I suppose the file could have been closed, or
> > the file descriptor could have been overwritten. What do you see in the
> > debugger?
>
> Philip, is there any input you are expecting from my side? Because I
> don't have an idea how I should debug this on the server side.
>
> Do you think the problem can be caused by the rather old version SVN
> 1.6.17 on the server? Either way, there must have happened something in
> the SVN 1.9 release as well, breaking this.
The problem is caused by apr not implementing file polling on Windows.
[[
else if (aprset[i].desc_type == APR_POLL_FILE) {
#if !APR_FILES_AS_SOCKETS
return APR_EBADF;
#else
fd = aprset[i].desc.f->filedes;
#endif
}
]]
Before Subversion 1.9 the code around the polling ignored errors and just checked for success.
I'll see if I can properly fix this (preferably in both Subversion and Apr), without reverting to just ignoring errors.
Bert
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Marc Strapetz <ma...@syntevo.com>.
On 14.08.2015 11:21, Philip Martin wrote:
> Marc Strapetz <ma...@syntevo.com> writes:
>
>> It's reproducible with an empty repository on the server (just
>> initialized with svnadmin) and a local repository which has been
>> prepared for the initial import:
>>
>> C:\temp\svn> svn status -v
>> 0 0 ? .
>> A - ? ? dir
>> A - ? ? dir\subfile
>> A - ? ? file
>>
>> C:\temp\svn> svn commit -m "initial import"
>> svn: E140004: Commit failed (details follow):
>> svn: E140004: Stream doesn't support this capability
>> svn: E000009: Polling for available data on filestream failed: Bad
>> file descriptor
>>
>> On the server, we are running SVN 1.6.17.
>
> That's the apr_poll() call in data_available_handler_apr() failing, and
> E000009 could be EBADF. I suppose the file could have been closed, or
> the file descriptor could have been overwritten. What do you see in the
> debugger?
Philip, is there any input you are expecting from my side? Because I
don't have an idea how I should debug this on the server side.
Do you think the problem can be caused by the rather old version SVN
1.6.17 on the server? Either way, there must have happened something in
the SVN 1.9 release as well, breaking this.
-Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> That's the apr_poll() call in data_available_handler_apr() failing, and
> E000009 could be EBADF.
Perhaps E000009 is not EBADF on Windows? Looking on Google I find
Error Code 9: The storage control block address is invalid. [ERROR_INVALID_BLOCK (0x9)]
I don't know what that means.
--
Philip Martin
WANdisco
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
Posted by Philip Martin <ph...@wandisco.com>.
Marc Strapetz <ma...@syntevo.com> writes:
> It's reproducible with an empty repository on the server (just
> initialized with svnadmin) and a local repository which has been
> prepared for the initial import:
>
> C:\temp\svn> svn status -v
> 0 0 ? .
> A - ? ? dir
> A - ? ? dir\subfile
> A - ? ? file
>
> C:\temp\svn> svn commit -m "initial import"
> svn: E140004: Commit failed (details follow):
> svn: E140004: Stream doesn't support this capability
> svn: E000009: Polling for available data on filestream failed: Bad
> file descriptor
>
> On the server, we are running SVN 1.6.17.
That's the apr_poll() call in data_available_handler_apr() failing, and
E000009 could be EBADF. I suppose the file could have been closed, or
the file descriptor could have been overwritten. What do you see in the
debugger?
Breakpoint 2, data_available_handler_apr (baton=0x669500,
data_available=0x7fffffffdccc)
at ../src/subversion/libsvn_subr/stream.c:955
955 status = apr_poll(&pfd, 1, &n, 0);
(gdb) p pfd.desc.f[0].filedes
$6 = 6
On Linux I can check that 6 a valid file descriptor for this process:
$ ls -l /proc/28574/fd/6
lr-x------ 1 pm pm 64 Aug 14 10:18 /proc/28574/fd/6 -> pipe:[612259]
--
Philip Martin
WANdisco
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Marc Strapetz <ma...@syntevo.com>.
On 14.08.2015 00:20, Branko Čibej wrote:
> On 13.08.2015 13:32, Marc Strapetz wrote:
>> On 27.07.2015 09:21, Branko Čibej wrote:
>>> On 27.07.2015 09:17, Marc Strapetz wrote:
>>>> One of our 1.9 (early-access) users is reporting problems when
>>>> performing remote commands, for example a copy URL->URL:
>>>>
>>>> org.apache.subversion.javahl.ClientException: Stream doesn't support
>>>> this capability
>>>> Bad file descriptor
>>>> svn: Polling for available data on filestream failed: Bad file
>>>> descriptor
>>>> at org.apache.subversion.javahl.SVNClient.copy(Native Method)
>>>> at ...
>>>>
>>>> He hasn't encountered such problems with 1.8 versions.
>>>>
>>>> AFAIU, he is connecting using SSH. Is this an SSH-related problem?
>>>> Could it be related to the underlying SSH client?
>>>
>>> Which platform is this? Can the user reproduce this problem with the
>>> command-line svn on the same machine?
>>
>> It's on Windows, in combination with SSH. I'm now able to reproduce
>> this problem myself and it looks like a regression to me:
>>
>> It's reproducible with our own Windows binaries as well as with the
>> WANdisco binaries. It's reproducible with Plink/Pageant as well as
>> with Trilead SSH. The commit works fine with Subversion 1.8.
>>
>> Is there any additional information/debugging I can do on my side?
>
> I'd still want to know if the command-line client works. If not, a
> minimal Java program using JavaHL that demonstrates the problem would be
> a real help.
No, the command-line client does not work: neither the binaries we are
building nor WANdisco's binaries.
It's reproducible with an empty repository on the server (just
initialized with svnadmin) and a local repository which has been
prepared for the initial import:
C:\temp\svn> svn status -v
0 0 ? .
A - ? ? dir
A - ? ? dir\subfile
A - ? ? file
C:\temp\svn> svn commit -m "initial import"
svn: E140004: Commit failed (details follow):
svn: E140004: Stream doesn't support this capability
svn: E000009: Polling for available data on filestream failed: Bad file
descriptor
On the server, we are running SVN 1.6.17.
-Marc
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Thomas Singer <th...@syntevo.com>.
On 14.08.2015 00:20, Branko Čibej wrote:
> On 13.08.2015 13:32, Marc Strapetz wrote:
>> On 27.07.2015 09:21, Branko Čibej wrote:
>>> On 27.07.2015 09:17, Marc Strapetz wrote:
>>>> One of our 1.9 (early-access) users is reporting problems when
>>>> performing remote commands, for example a copy URL->URL:
>>>>
>>>> org.apache.subversion.javahl.ClientException: Stream doesn't support
>>>> this capability
>>>> Bad file descriptor
>>>> svn: Polling for available data on filestream failed: Bad file
>>>> descriptor
>>>> at org.apache.subversion.javahl.SVNClient.copy(Native Method)
>>>> at ...
>>>>
>>>> He hasn't encountered such problems with 1.8 versions.
>>>>
>>>> AFAIU, he is connecting using SSH. Is this an SSH-related problem?
>>>> Could it be related to the underlying SSH client?
>>>
>>> Which platform is this? Can the user reproduce this problem with the
>>> command-line svn on the same machine?
>>
>> It's on Windows, in combination with SSH. I'm now able to reproduce
>> this problem myself and it looks like a regression to me:
>>
>> It's reproducible with our own Windows binaries as well as with the
>> WANdisco binaries. It's reproducible with Plink/Pageant as well as
>> with Trilead SSH. The commit works fine with Subversion 1.8.
>>
>> Is there any additional information/debugging I can do on my side?
>
> I'd still want to know if the command-line client works.
No, it doesn't. That's what Marc meant with "It's reproducible with our
own Windows binaries as well as with the WANdisco binaries." The problem
is reproducible independent of SmartSVN.
--
Thomas
Re: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this
capability" errors
Posted by Branko Čibej <br...@wandisco.com>.
On 13.08.2015 13:32, Marc Strapetz wrote:
> On 27.07.2015 09:21, Branko Čibej wrote:
>> On 27.07.2015 09:17, Marc Strapetz wrote:
>>> One of our 1.9 (early-access) users is reporting problems when
>>> performing remote commands, for example a copy URL->URL:
>>>
>>> org.apache.subversion.javahl.ClientException: Stream doesn't support
>>> this capability
>>> Bad file descriptor
>>> svn: Polling for available data on filestream failed: Bad file
>>> descriptor
>>> at org.apache.subversion.javahl.SVNClient.copy(Native Method)
>>> at ...
>>>
>>> He hasn't encountered such problems with 1.8 versions.
>>>
>>> AFAIU, he is connecting using SSH. Is this an SSH-related problem?
>>> Could it be related to the underlying SSH client?
>>
>> Which platform is this? Can the user reproduce this problem with the
>> command-line svn on the same machine?
>
> It's on Windows, in combination with SSH. I'm now able to reproduce
> this problem myself and it looks like a regression to me:
>
> It's reproducible with our own Windows binaries as well as with the
> WANdisco binaries. It's reproducible with Plink/Pageant as well as
> with Trilead SSH. The commit works fine with Subversion 1.8.
>
> Is there any additional information/debugging I can do on my side?
I'd still want to know if the command-line client works. If not, a
minimal Java program using JavaHL that demonstrates the problem would be
a real help.
-- Brane