[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: AW: "Permission denied" committing to sourceforge

From: Branko Čibej <brane_at_apache.org>
Date: Fri, 10 Aug 2018 14:35:33 +0200

On 10.08.2018 14:30, Branko Čibej wrote:
> On 10.08.2018 13:37, Markus Schaber wrote:
>> Hi, Tom,
>> 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.

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.

-- Brane
Received on 2018-08-10 14:35:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.