Re: AW: "Permission denied" committing to sourceforge

[Branko Čibej]

On 10.08.2018 14:30, Branko Čibej wrote:
> On 10.08.2018 13:37, Markus Schaber wrote:
>> Hi, Tom,
>>
>> Von: Thomas Singer  
>> 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:  SourceForge User 
> Password for 'HinzKunz': 
> svn: E13: Commit failed (details below):
> svn: E13: 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

Re: AW: "Permission denied" committing to sourceforge

[Branko Čibej]

On 10.08.2018 13:37, Markus Schaber wrote:
> Hi, Tom,
>
> Von: Thomas Singer  
> 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:  SourceForge User 
 Password for 'HinzKunz': 
 svn: E13: Commit failed (details below):
 svn: E13: 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.

-- Brane