On 10.08.2018 16:06, Markus Schaber wrote:
> Hi, Brane,
>
> Von: Branko Čibej <brane_at_apache.org>
>> On 10.08.2018 14:30, Branko Čibej wrote:
>>> On 10.08.2018 13:37, Markus Schaber wrote:
>>>> Von: Thomas Singer <thomas.singer_at_syntevo.com> On 2018-08-10 9:52,
>>>> Branko Čibej wrote:
>>>>> On 10.08.2018 09:44, Stefan Sperling wrote:
>>>>>> On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote:
>>>>>>> When trying to commit to a sourceforge repository using a
>>>>>>> self-compiled SVN binary, I'm getting following error:
>>>>>>>
>>>>>>> D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message"
>>>>>>> Authentication realm: <https://svn.code.sf.net:443> SourceForge
>>>>>>> User Password for 'HinzKunz': ************
>>>>>>> svn: E000013: Commit failed (details below):
>>>>>>> svn: E000013: Can't create directory
>>>>>>> '/svn/p/irrlicht/code/db/transactions/5634-1.txn': Permission
>>>>>>> denied
>>>>>>>
>>>>>>> Could this mean that we have built the SVN binary incomplete
>>>>>>> (missing a part that is required for committing to sourceforge but
>>>>>>> not other SVN repositories)? How can I get some helpful logging? Thanks in advance.
>>>>>>>
>>>>>> I believe you'll need to ask sourceforge about this. This looks
>>>>>> like a server-side problem and there is nothing an SVN client could do about it.
>>>>> More specifically, it looks like filesystem permissions on the
>>>>> repository storage are incorrect.
>>>> Thanks. That's what I thought initially, too, simply guessing from the error message. But the user who reported the problem writes that with his default SVN binaries the commit succeeded for him, and I'm not sure that's it's not a problem with our SVN binaries.
>>>>
>>>> Is it possible that there's a difference in protocols?
>>>>
>>>> If the one user uses https://, and the other uses svn:// or svn+ssh:// protocols, the server side has different software, probably running under different user account and permissions.
>>> Of course, but it's still the server administrators responsibility to
>>> make things work (i.e., set process/file ownership and permissions
>>> correctly) if they support both http:// and svn:// protocols. Nothing
>>> on the client side can affect that.
> Agreed.
>
>> By the way: the protocol used is determined by the working copy, not by the client software; unless some info is missing from your report, both clients are using the same protocol.
> Hmm, yes it's in the working copy. But that "missing information" was what I suspected. One part (which is not necessarily covered by working copy) could be user name, especially with svn+ssh:// - on the other hand, the pasted example uses https:// URLs. So I withdraw everything. :-)
Actually, the username could be different for https:// as well. In
theory, differently compiled clients could use different credentials caches.
-- Brane
Received on 2018-08-11 13:18:12 CEST