Re: AW: AW: "Permission denied" committing to sourceforge

[Thomas Singer]

On 2018-08-11 13:18, Branko Čibej wrote:

On 10.08.2018 16:06, Markus Schaber wrote:

Hi, Brane,

Von: Branko Čibej 

On 10.08.2018 14:30, Branko Čibej wrote:

On 10.08.2018 13:37, Markus Schaber wrote:

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.

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


The user ensured to have used the same working copy. Is there some way 
to debug it to find out why his SVN binary behaves different then ours? 
Thanks in advance.


-- Tom

Re: AW: AW: "Permission denied" committing to sourceforge

[Branko Čibej]

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

AW: AW: "Permission denied" committing to sourceforge

[Markus Schaber]

Hi, Brane,

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

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. :-)


Mit freundlichen Grüßen

Markus Schaber

CODESYS® Eine Marke der 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: 
http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.