Re: A question about Path-Based Authorization in svn
On 28.07.2015 11:23, David Aldrich wrote: groupA = fred groupB = fred, jane [myRepo:/] @groupA = rw @groupB = r Is fred's access to myRepo:/ 'rw' or 'r'? The user always gets the union of all rights given her by a rule; in other words, the maximum access rights defined in any entry in a rule. Thanks for your answer. So, to be absolutely clear, fred's access is 'rw'? Yes. -- Brane
A question about Path-Based Authorization in svn
Hi Path-Based Authorization is described here: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html Having read that description, it is not clear to me what happens in this situation: groupA = fred groupB = fred, jane [myRepo:/] @groupA = rw @groupB = r Is fred's access to myRepo:/ 'rw' or 'r'? Does the order of the groups (below the [myRepo:/] statement) matter? (We are running svn 1.8). Best regards David
RE: A question about Path-Based Authorization in svn
groupA = fred groupB = fred, jane [myRepo:/] @groupA = rw @groupB = r Is fred's access to myRepo:/ 'rw' or 'r'? The user always gets the union of all rights given her by a rule; in other words, the maximum access rights defined in any entry in a rule. Thanks for your answer. So, to be absolutely clear, fred's access is 'rw'? David
Re: A question about Path-Based Authorization in svn
On 28.07.2015 10:11, David Aldrich wrote: Hi Path-Based Authorization is described here: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html Having read that description, it is not clear to me what happens in this situation: groupA = fred groupB = fred, jane [myRepo:/] @groupA = rw @groupB = r Is fred's access to myRepo:/ 'rw' or 'r'? The user always gets the union of all rights given her by a rule; in other words, the maximum access rights defined in any entry in a rule. Does the order of the groups (below the [myRepo:/] statement) matter? No, it does not. -- Brane
RE: A question about Path-Based Authorization in svn
Thanks for your answer. So, to be absolutely clear, fred's access is 'rw'? Yes. Thanks again, David
Broken SVN revision paths encoding
Hi there, Somehow I was able to commit a file with a broken filename encoding and now the svn client can no longer process the log messages from the server! For example I commited the file fooä.bar and when I then try to svn log I get this: svn: E130003: The REPORT response contains invalid XML (200 OK) However, in wireshark I can see this coming in (stripped to the interesting lines): S:log-item S:added-pathfoo\344.file/S:added-path /S:log-item The clients svn is not the latest, but a newer version does not work either: svn version svn, version 1.8.10 (r1615264) compiled Aug 10 2014, 15:48:46 on x86-microsoft-windows Any good ideas how we can bring the repository back to be fully functional? Cheers
Re: Broken SVN revision paths encoding
What client (including version) did you use to commit… and against what kind of server? Subversion's clients properly encode characters to utf-8 as far as we know, but perhaps you used some not standard client for the commit. (Newer servers should perform more verifications; that is why that answer is also relevant) Bert Sent from Surface From: dpsen...@apache.org Sent: Tuesday, July 28, 2015 4:11 PM To: users@subversion.apache.org Hi there, Somehow I was able to commit a file with a broken filename encoding and now the svn client can no longer process the log messages from the server! For example I commited the file “fooä.bar” and when I then try to svn log I get this: svn: E130003: The REPORT response contains invalid XML (200 OK) However, in wireshark I can see this coming in (stripped to the interesting lines): S:log-item S:added-pathfoo\344.file/S:added-path /S:log-item The clients svn is not the latest, but a newer version does not work either: svn –version svn, version 1.8.10 (r1615264) compiled Aug 10 2014, 15:48:46 on x86-microsoft-windows Any good ideas how we can bring the repository back to be fully functional? Cheers
Re: Broken SVN revision paths encoding
Thanks Bert for your answer. I've used the latest tortoisehg which used to ship the subversion bindings but stopped to do so. That is entirely documented here: https://bitbucket.org/tortoisehg/thg/wiki/libsvn The server on the other ends dates back to 2011. I believe it is something along 1.4, but I might be wrong and will eventually correct myself tomorrow morning. For the completeness of the story let me outline what happened: Beforehand, as you might have guessed I am using hg as my local svn client because of obvious reasons (working offline, faster history queries and faster working copy queries among others). I've copied some random files that had to be versioned from a network share without knowing that the filenames might be encoded badly. When I tried to check in the files in question tortoisehg complained that he could not find the file. That should have got me thinking, but getting the job done was fairly easy using the command line and thus I did not bother. So then I pushed the changesets to svn which worked flawlessly. But then the continuous integration system began to complain and I started to comprehend that I've messed it up for good. And it proved that i was not wrong in my assumption. We're now unable to svn log, nore the build/test environments and we have to find a way to fix the issue and eventually find a solution to prevent future trouble. Ideas welcome.. Cheers What client (including version) did you use to commit… and against what kind of server? Subversion's clients properly encode characters to utf-8 as far as we know, but perhaps you used some not standard client for the commit. (Newer servers should perform more verifications; that is why that answer is also relevant) Bert Sent from Surface *From:* dpsen...@apache.org *Sent:* Tuesday, July 28, 2015 4:11 PM *To:* users@subversion.apache.org Hi there, Somehow I was able to commit a file with a broken filename encoding and now the svn client can no longer process the log messages from the server! For example I commited the file “fooä.bar” and when I then try to svn log I get this: svn: E130003: The REPORT response contains invalid XML (200 OK) However, in wireshark I can see this coming in (stripped to the interesting lines): S:log-item S:added-pathfoo\344.file/S:added-path /S:log-item The clients svn is not the latest, but a newer version does not work either: svn –version svn, version 1.8.10 (r1615264) compiled Aug 10 2014, 15:48:46 on x86-microsoft-windows Any good ideas how we can bring the repository back to be fully functional? Cheers
