On 10.08.2018 13:37, Markus Schaber wrote: > Hi, Tom, > > 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. -- Brane