You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Thomas Singer <th...@syntevo.com> on 2018/08/10 06:44:08 UTC
"Permission denied" committing to sourceforge
Hi,
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.
--
Best regards,
Thomas Singer
Re: "Permission denied" committing to sourceforge
Posted by Thomas Singer <th...@syntevo.com>.
Sorry, the problem was that the end-user used a different case of the
user name than what he told me to use.
--
Best regards,
Thomas Singer
On 13/08/2018 15:00, Daniel Shahaf wrote:
> Thomas Singer wrote on Mon, 13 Aug 2018 14:56 +0200:
>> 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.
>
> The simplest explanation is that it's a cygwin svn.exe v. a windows
> svn.exe. Those two would use different config dirs and hence different
> credential caches. You can use the 'svn auth' command to list the
> saved credentials.
>
Re: "Permission denied" committing to sourceforge
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Thomas Singer wrote on Mon, 13 Aug 2018 14:56 +0200:
> 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.
The simplest explanation is that it's a cygwin svn.exe v. a windows
svn.exe. Those two would use different config dirs and hence different
credential caches. You can use the 'svn auth' command to list the
saved credentials.
Re: AW: AW: "Permission denied" committing to sourceforge
Posted by Thomas Singer <th...@syntevo.com>.
On 2018-08-11 13:18, Branko Čibej wrote:
> 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 <th...@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
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
Posted by Branko Čibej <br...@apache.org>.
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 <th...@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
AW: AW: "Permission denied" committing to sourceforge
Posted by Markus Schaber <m....@codesys.com>.
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 <th...@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. :-)
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.schaber@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.
Re: AW: "Permission denied" committing to sourceforge
Posted by Branko Čibej <br...@apache.org>.
On 10.08.2018 14:30, Branko Čibej wrote:
> On 10.08.2018 13:37, Markus Schaber wrote:
>> Hi, Tom,
>>
>> Von: Thomas Singer <th...@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
Re: AW: "Permission denied" committing to sourceforge
Posted by Branko Čibej <br...@apache.org>.
On 10.08.2018 13:37, Markus Schaber wrote:
> Hi, Tom,
>
> Von: Thomas Singer <th...@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.
-- Brane
AW: "Permission denied" committing to sourceforge
Posted by Markus Schaber <m....@codesys.com>.
Hi, Tom,
Von: Thomas Singer <th...@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.
Regards,
Markus
Re: "Permission denied" committing to sourceforge
Posted by Thomas Singer <th...@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:
>>> Hi,
>>>
>>> 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.
>>>
>>> --
>>> Best regards,
>>> Thomas Singer
>> Hi Thomas,
>>
>> 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.
>
> -- Brane
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.
-- Tom
Re: "Permission denied" committing to sourceforge
Posted by Branko Čibej <br...@apache.org>.
On 10.08.2018 09:44, Stefan Sperling wrote:
> On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote:
>> Hi,
>>
>> 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.
>>
>> --
>> Best regards,
>> Thomas Singer
> Hi Thomas,
>
> 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.
-- Brane
Re: "Permission denied" committing to sourceforge
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote:
> Hi,
>
> 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.
>
> --
> Best regards,
> Thomas Singer
Hi Thomas,
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.