On 10.08.2018 16:06, Markus Schaber wrote:
> Hi, Brane,
> Von: Branko Čibej <br...@apache.org> 
>> On 10.08.2018 14:30, Branko Čibej wrote:
>>> On 10.08.2018 13:37, Markus Schaber wrote:
>>>> Von: Thomas Singer <thomas.sin...@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

Reply via email to