Re: Subversion 1.8.9 repository access issue [Urgent]
Hi, On 7 Jul 2014, at 13:48, Branko Čibej br...@wandisco.com wrote: The question that started this thread was why a BDB database could not be opened. The answer is, because the BDB back-end was not built. We don't even know that the old and new BDB versions are different. The user informed me that his resolution was a dump with the previous version followed by an import with the current one. Andreas
RE: Problems with subversion
Hello, I connect to a remote file system through a XVC terminal emulator. Platform: UNIX linux Subversion version: 1.1.4 Following my previous e-mail below, I was able to establish that the problem resides in my repository. Whenever I issue any subversion command to the repository like: svnlook tree /altroot/ENGDATA/DeFRAC/defracdev/repository The problem now I face is the following: svn: Error opening db lockfile svn: Can't get shared lock on file 'locks/db.lock': No locks available It seems a file locking problem... The output of command: df -T /altroot/ENGDATA/DeFRAC/defracdev/repository is the following: Filesystem Type 1K-blocks Used Available Use% Mounted on engarchive:/export/engarchive/ENGDATA nfs 528417056 384972448 138160448 74% /altroot/ENGDATA Any ideas? Many thanks Paolo Paolo Giuliani Reactor Physics Group Nuclear Technology Branch EDF Energy Barnett Way Barnwood Gloucester GL4 3RS ( Tel: 01452 654346 (Internal 777 4346) Ê Fax: 01452 654916 * E-mail: paolo.giuli...@edf-energy.com http://www.edfenergy.com - Powering the low carbon generation Ask yourself whether you need a hard copy. If you do, print it double sided __ From: Giuliani Paolo Sent: 02 July 2014 15:43 To: 'users@subversion.apache.org' Subject: Problems with subversion Hello, I have been using subversion for while now and without problems. But recently when I was trying to commit my changes (svn commit -m DeFrac final changes), from my local working copy, I got the following error message: svn: Commit failed (details follow): svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///ENGDATA/DeFRAC/defracdev/repository/maintv2/trunk file:///\\ENGDATA\DeFRAC\defracdev\repository\maintv2\trunk ' svn: Error opening db lockfile svn: Can't get shared lock on file '/ENGDATA/DeFRAC/defracdev/repository/locks/db.lock': No locks available I tried to issue the recover subcommand (svnadmin recover /altroot/ENGDATA/DeFRAC/defracdev/repository), but still I received the following message: Repository lock acquired. Please wait; recovering the repository may take some time... Recovery completed. svn: Error opening db lockfile svn: Can't get shared lock on file '/altroot/ENGDATA/DeFRAC/defracdev/repository/locks/db.lock': No locks available I would appreciate your help. Many thanks Paolo Paolo Giuliani Reactor Physics Group Nuclear Technology Branch EDF Energy Barnett Way Barnwood Gloucester GL4 3RS ( Tel: 01452 654346 (Internal 777 4346) Ê Fax: 01452 654916 * E-mail: paolo.giuli...@edf-energy.com http://www.edfenergy.com - Powering the low carbon generation Ask yourself whether you need a hard copy. If you do, print it double sided This e-mail, and any attachments, is confidential and for the use of the addressee only. If you are not the intended recipient, please telephone +44 (0) 1355 846000. We do not accept legal responsibility for this e-mail or any viruses. All e-mails sent and received by us are monitored. Contracts cannot be concluded with us by e-mail. This message has been sent from EDF Energy Nuclear Generation Ltd , a company registered in England and Wales No. 03076445, with registered office at Barnett Way, Barnwood, Gloucester, GL4 3RS.
RE: Problems with subversion
If I remember correctly Subversion 1.1 used Berkeley DB (BDB) for various purposes - for example the repository format might be BDB. BDB relied upon file locking to enforce data consistency. As I mentioned not all implementations of NFS servers fully implement file locking - this is why you are receiving these errors. My recommendation is that you should migrate to a newer version of Subversion /and/ to a service based serving of the Subversion data rather than using file:// based access to the repository. David. -- David Griersonhttps://confluence.bskyb.com/display/~DGR02/ - SDLC Tools Specialist Sky Broadcasting - Customer Business Systems - SDLC Toolshttps://confluence.bskyb.com/display/TwikiImport/ Tel: +44 1506 325100 / Email: david.grier...@bskyb.commailto:david.grier...@bskyb.com / Chatter: CBS SDLC Toolshttps://bskyb.my.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F920008Z8b Watermark Building, Alba Campus, Livingston, EH54 7HH From: Giuliani Paolo [mailto:paolo.giuli...@edf-energy.com] Sent: 09 July 2014 10:31 To: users@subversion.apache.org Subject: RE: Problems with subversion Hello, I connect to a remote file system through a XVC terminal emulator. Platform: UNIX linux Subversion version: 1.1.4 Following my previous e-mail below, I was able to establish that the problem resides in my repository. Whenever I issue any subversion command to the repository like: svnlook tree /altroot/ENGDATA/DeFRAC/defracdev/repository The problem now I face is the following: svn: Error opening db lockfile svn: Can't get shared lock on file 'locks/db.lock': No locks available It seems a file locking problem... The output of command: df -T /altroot/ENGDATA/DeFRAC/defracdev/repository is the following: Filesystem Type 1K-blocks Used Available Use% Mounted on engarchive:/export/engarchive/ENGDATA nfs 528417056 384972448 138160448 74% /altroot/ENGDATA Any ideas? Many thanks Paolo Paolo Giuliani Reactor Physics Group Nuclear Technology Branch EDF Energy Barnett Way Barnwood Gloucester GL4 3RS ( Tel: 01452 654346 (Internal 777 4346) Ê Fax: 01452 654916 * E-mail: paolo.giuli...@edf-energy.commailto:paolo.giuli...@edf-energy.com http://www.edfenergy.com - Powering the low carbon generation Ask yourself whether you need a hard copy. If you do, print it double sided __ From: Giuliani Paolo Sent: 02 July 2014 15:43 To: 'users@subversion.apache.org' Subject: Problems with subversion Hello, I have been using subversion for while now and without problems. But recently when I was trying to commit my changes (svn commit -m DeFrac final changes), from my local working copy, I got the following error message: svn: Commit failed (details follow): svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///ENGDATA/DeFRAC/defracdev/repository/maintv2/trunkfile:///\\ENGDATA\DeFRAC\defracdev\repository\maintv2\trunk' svn: Error opening db lockfile svn: Can't get shared lock on file '/ENGDATA/DeFRAC/defracdev/repository/locks/db.lock': No locks available I tried to issue the recover subcommand (svnadmin recover /altroot/ENGDATA/DeFRAC/defracdev/repository), but still I received the following message: Repository lock acquired. Please wait; recovering the repository may take some time... Recovery completed. svn: Error opening db lockfile svn: Can't get shared lock on file '/altroot/ENGDATA/DeFRAC/defracdev/repository/locks/db.lock': No locks available I would appreciate your help. Many thanks Paolo Paolo Giuliani Reactor Physics Group Nuclear Technology Branch EDF Energy Barnett Way Barnwood Gloucester GL4 3RS ( Tel: 01452 654346 (Internal 777 4346) Ê Fax: 01452 654916 * E-mail: paolo.giuli...@edf-energy.commailto:paolo.giuli...@edf-energy.com http://www.edfenergy.com - Powering the low carbon generation Ask yourself whether you need a hard copy. If you do, print it double sided This e-mail, and any attachments, is confidential and for the use of the addressee only. If you are not the intended recipient, please telephone +44 (0) 1355 846000. We do not accept legal responsibility for this e-mail or any viruses. All e-mails sent and received by us are monitored. Contracts cannot be concluded with us by e-mail. This message has been sent from EDF Energy Nuclear Generation Ltd , a company registered in England and Wales No. 03076445, with registered office at Barnett Way, Barnwood, Gloucester, GL4 3RS. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail
Re: SVN 1.8 Kerberos Client problems
Hi! Firstly, thanks for your quick answer! On 8 July 2014 21:24, Lieven Govaerts l...@mobsol.be wrote: Hi Nico, [...] Everything ran fine so far. I then upgraded to TSVN 1.8.7 which ships with svn 1.8.9 binaries. Now, on every repository involving action I get kerberos errors in my apache log: [Tue Jul 08 15:08:10 2014] [error] [client 192.168.1.152] gss_accept_sec_context() failed: No credentials were supplied, or the credentials were unavailable or inaccessible (, Unknown error) Strange thing is, TSVN works fine from a user perspective (no error displayed whatsoever...). I then tried to use the svn command line binaries, same result, evrythings works, but apache error log is DOSed with these error entries. That's because you have this directive in your apache config: KrbMethodK5Passwd on With this configuration, mod_auth_kerb will offer both Negotiate and Basic authentication. Your logs show that Negotiate authentication fails, but in this case svn will automatically fall back to Basic authentication, which succeeds. I tried to either prefer or deny BulkUpdates on the server, nothing changes. This option has nothing to do with authentication, it specifies how - after authentication succeeded - svn+serf will communicate with mod_dav_svn. Apparently, yes :) I tried this option, because to me it seemed as if the svn client reauthenticates all the time during a svn operation (e.g. update). So I thought this might help - i.e. many requests vs. one big. I excpected to happen the error only once when using BulkUpdates, because it should only authenticate once. Unfortunately it seems I'm wrong :| From the linux cmd (on the svn server itself), I can use kerberos (kinit + svn command afterwards) just fine, without any errors popping up in the apache log. Which GSSAPI implementation are you using on the server? MIT? Heimdal? Which versions? [root@svn log]# rpm -qa | grep krb krb5-libs-1.10.3-15.el6_5.1.x86_64 python-krbV-1.0.90-3.el6.x86_64 krb5-devel-1.10.3-15.el6_5.1.x86_64 krb5-workstation-1.10.3-15.el6_5.1.x86_64 pam_krb5-2.3.11-9.el6.x86_64 Info about krb5-workstation: Installed Packages Name: krb5-workstation Arch: x86_64 Version : 1.10.3 Release : 15.el6_5.1 Size: 1.0 M Repo: installed From repo : updates Summary : Kerberos 5 programs for use on workstations URL : http://web.mit.edu/kerberos/www/ License : MIT Description : Kerberos is a network authentication system. The krb5-workstation : package contains the basic Kerberos programs (kinit, klist, kdestroy, : kpasswd). If your network uses Kerberos, this package should be : installed on every workstation. Debugging this stuff will not be easy. Most likely you'll find some more information in the Kerberos implementation logging, which is configured in your krb5.conf file. On my system the log file is /var/log/krb5.log. Try to increase the log level to get more detailed error information. The best alternative is to find out what's going over the wire. Disable your SSL configuration and set KrbMethodK5Passwd to off (on a test server) and use Wireshark to trace all traffic between your Windows client and svn server. Wireshark on Windows can decode the SPNego tokens in the Authorization headers (at least for NTLM but I suppose for Kerberos also). This allows you to see if all info is correct (domain, username etc). If you want you can send me the wireshark trace privately and I'll have a look. I tried to do some testing, and got weird results. First of all, I don't get the kerberos error mentioned above anymore. Instead TSVN and the command line client just hang on every operation. Well, it seems they hang, but they finish eventually 30 minutes later, even on the simplest actions. This was on a server that is not part of our domain. (maybe the server not being part of our domain was the problem yesterday, because it would try negotiate without success then) Next, I switched to a Windows 2008 sevrer which is part of our domain. I cleaned any user properties (e.g. subversion folder and saved auth stuff) before every run. I tested with svn command line clients version 1.7.10 and 1.8.9 (shipped with the corresponding TSVN version) Test command: Simple checkout of a project svn client version 1.7.10 1. KrbMethodNegotiate on: asks for password, works 2. KrbMethodNegotiate off: asks for password, works svn client version 1.8.9 3. KrbMethodNegotiate on: does not ask for password, does not always work 4. KrbMethodNegotiate off: asks for password, works Test case 1 and 2 seem reasonable, IIRC neon just can't do negotiate but the password fallback works. Test case 4 seems to work well, i.e. the password fallback is enforced and everything works, even with serf in place. Test case 3 produces very strange results. First I get random svn: E200014: Checksum mismatch errors and the checkout just stops.
Can't read length line in file X [500, #200002]
Hi I'm using Subversion 1.6.9 via the CollabNet Subversion Server. When trying to check out part of the repository I had an error and saw the following in the Apache logs: [Wed Jul 09 10:26:35 2014] [error] [client X] Provider encountered an error while streaming a REPORT response. [500, #0] [Wed Jul 09 10:26:36 2014] [error] [client X] A failure occurred while driving the update report editor [500, #22] [Wed Jul 09 10:26:36 2014] [error] [client X] Can't read length line in file Y [500, #22] The revision that is failing is about 49 MB and was created in 2009. Subversion is hosted on Windows Server 2003. Looking through the mailing list archive, I see 3 options: - restore a backup, which hasn't worked - dump before the damaged revision, after the damaged revision and then reproduce the change. Unfortunately I don't know all that was changed in this revision, due to it occurring 5 years ago - if you are willing to look at it - provide you the revision - provide you an output of a script I know that this is an old version of Subversion, so would I be able to recover the file or part of the file, or would the only solution be to start a new repository with what I can recover? Thank you Trevor
Re: Can't read length line in file X [500, #200002]
Hi I looked at the log of revision comments and found that the broken revision is purely adding files that are from another repository at a particular revision number. I'm in the process of get a copy of that repository. I took a dump of the repository with the corrupt revision up to that broken revision. When I tried to take an incremental dump from after that revision to head, a few revisions got dumped, but I then received the Can't read length line in file error for the broken revision. I'm trying to fix the repository using the solution described in the archives here http://svn.haxx.se/users/archive-2006-05/0896.shtml, where I'd reproduce the broken revision. I there a way to get a copy of the all the revisions after the broken one to apply to a new repository? Thank you Trevor On 9 July 2014 11:18, Trevor Dearham trevor.dear...@gmail.com wrote: Hi I'm using Subversion 1.6.9 via the CollabNet Subversion Server. When trying to check out part of the repository I had an error and saw the following in the Apache logs: [Wed Jul 09 10:26:35 2014] [error] [client X] Provider encountered an error while streaming a REPORT response. [500, #0] [Wed Jul 09 10:26:36 2014] [error] [client X] A failure occurred while driving the update report editor [500, #22] [Wed Jul 09 10:26:36 2014] [error] [client X] Can't read length line in file Y [500, #22] The revision that is failing is about 49 MB and was created in 2009. Subversion is hosted on Windows Server 2003. Looking through the mailing list archive, I see 3 options: - restore a backup, which hasn't worked - dump before the damaged revision, after the damaged revision and then reproduce the change. Unfortunately I don't know all that was changed in this revision, due to it occurring 5 years ago - if you are willing to look at it - provide you the revision - provide you an output of a script I know that this is an old version of Subversion, so would I be able to recover the file or part of the file, or would the only solution be to start a new repository with what I can recover? Thank you Trevor
Subversion Exception! line 143: assertion failed (stream-read_fn != NULL)
Hi, I send you the message I received when I was trying to commit an update on a file that I was working with. I use a VPN connection to use SVN, and, at the first two attempts of commit I was not able to connect to the VPN, therefore, I cancelled the transaction. Once I was able to connect to VPN, I tried to commit the change that I did, and the process appeared to be right, because it was sending the file and the progress bar was almost completed, but, instead of a confirmation, I received a window saying that Tortoise SVN X64 has crashed, and, then, received the following message: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_subr\stream.c' line 143: assertion failed (stream-read_fn != NULL) --- Aceptar Thanks in advance for your help. Regards, -- *Stephany Escobar*
SVN 1.8.8 exception
I haven't found any reports posted in the archives that are an exact match to this issue, so I'm posting this here as requested by the error message. The error message is as follows: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.6\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c' line 1039: assertion failed (move_dst_revision == expected_move_dst_revision || status == svn_wc__db_status_not_present) --- OK --- At the time of the error, I was executing an update on a working copy folder from TortoiseSVN v1.8.6. There had only been one check-in since my last update, and it only contained code modifications (no moves, deletions, etc.). My working copy, however, had code modifications, renames, and deletions. I did find one similar error message posted in the archives: http://mail-archives.apache.org/mod_mbox/subversion-dev/201310.mbox/%3c776311a518f6f642962ec561a9184090d57dc62...@thsonep02cmb01p.one-02-priv.grp%3e Posted by Neil BIRD on Oct. 25, 2013. However, this issue was logged against SVN v1.8.3, and the response claims it should be fixed in 1.8.4, so I'm posting at again so that it stays on the radar if it's still an issue. BTW, I'd appreciate being CC'ed on any replies to this thread, since I'm not a subscriber. Thanks. Jeff A. ***Disclaimer*** The contents of this e-mail and any file transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. The content may also contain legal, professional or other privileged information. If you received this e-mail in error, please destroy it immediately. You should not copy or use it for any purpose nor disclose its contents to any other person. The views stated herein do not necessarily represent the view of the Company. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. The Company does not accept any liability for viruses. Akron Brass Company 343 Venture Blvd. Wooster, Ohio 44691 Telephone 330-287-7000 Fax 330-264-2944
Re: How to control access of a subversion repo subfolder via AD groups
On 7/7/14 3:56 AM, Ankush Grover wrote: I am trying to setup Subversion authentication through Active Directory authentication and authorization through Active Directory groups.Everything is working fine but the issue I am facing is when I want to restrict access to subdirectorys of a subversion repository. For ex: there is a repo with a name ankushtest and it has a subdirectory test, now I want some users which are in AD group to be able to read or commit to subdirectory test only. This access is working fine through SVN clients like Tortoise etc.. but when I try to open the same on a browser, the user which has access only to subdirectory test is able to see the all the directorys or files under repo ankushtest. How this is working is like that, if a user types the complete url for the test directory like http://svn.example.com/src/ankushtest/test; then browser is showing the all the files directorys of a repo. In the Apache logs I see the below warning whenever I click on the url http://svn.example.com/src/ankushtest/test; and this test directory on the browser shows all the files directorys whereas this directory has only 1 file and a sub-directory in it. Mon Jul 07 14:21:47 2014] [warn] mod_dav_svn: nested Location '/src/ankushtest/test' hinders access to 'test1' in SVNPath Location '/src/ankushtest' You should only have a single Location block for your repository. That warning message is telling you as much. When you use multiple Location blocks like this then the /src/ankushtest and the /src/ankushtest/test both are Locations that point at the root of the repository. The reason you're seeing this work with a Subversion client is because the Subversion client often accesses things under the root of the repository with opaque URLs which still go through the /src/ankushtest Location block rather than the /src/ankushtest/test Location. If you want to do path based access control within the repository you must use mod_authz_svn to do this. It knows how to handle the opaque URLs and properly provide access control. Beyond opaque URLs there are also requests that provide details for child paths other than just the path the request uses in the HTTP request-line, which is all that would be matched by Location. Setting up mod_authz_svn is generally described in the SVN Book here: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir Unfortunately, using mod_authz_svn is complicated by your desire to use AD groups. The group membership that Apache httpd uses is not available to mod_authz_svn, this is just a limitation of the way Apache httpd authentication and authorization works. So in order to do what you want you need to provide the group membership information to mod_authz_svn separately. This is done by adding the [groups] section to the AccessFile. Obviously maintaining this by hand is tedious so people usually automate this. It's popular to use this tool to do that automation: http://thoughtspark.org/2009/01/20/using-ldap-groups-with-subversion-s-authz-file/ Though there are also commercial products that can do this and much more such as WANDisco's Access Control product: http://wandisco.com/subversion/accesscontrol I suspect there are other commercial products that can manage this for you as well though I'm not as familiar with their features (full disclosure I work for WANdisco). If you don't go the route of a commercial product to manage this I'd suggest that you do the following things beyond just using mod_authz_svn. * Include the SVNPathAuthz short_circuit directive in your Location blocks for SVN. This avoids running authentication/authorization processing as sub-requests for paths that aren't in the request-line but that must be accessed to service the request. The default uses much more expensive sub-requests, which while secure for any configuration are much more expensive. Almost not configurations actually need the default setting. * You mention that you're using Subversion 1.7, but Subversion 1.8 adds the AuthzSVNGroupsFile directive that permits this group data to be in a separate file from your access configuration. This should make it easier to configure.
Re: Adding [svn users] to subject
On 7/7/14 6:23 AM, Notes Jonny wrote: Have you thought about adding [svn users] to prefix the subject of emails? It would make my mailbox simpler to prioritise all emails.. Currently I need to read the subjects.. or implement some complex filtering to folder of svn users emails.. Modifying mail going to mailing lists is a very bad idea these days. It's becoming increasingly common for mail providers to sign mail and then publish DNS records that tell receivers that they can reject mail that is not properly signed. Modifying the mail then means these signatures no longer validate and the mail may be rejected. Yahoo changed their DMARC settings in April of this year to tell receivers that they should start rejecting mail that was not signed. This caused many mailing lists that are doing exactly what you suggest to start dropping mail coming from Yahoo users. The solutions for this as outlined here are not great: http://www.dmarc.org/faq.html#s_3 http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail It basically comes down to: 1) Don't modify mail. 2) Start modifying the mail in more intrusive ways. At the Apache Software Foundation for lists that don't follow the first option they've adopted the .invalid option: http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Add_fixed_string_such_as_.invalid_to_addresses Which means for domains where DMARC configuration would break the mail the sender mail is changed to have a .invalid postfix on the sender's address. For example in the case of Yahoo u...@yahoo.com.invalid This would be particularly problematic for our users@ list because often we have posters who are not subscribed to the list and would like to receive the responses back. Responders would have to pay attention to the addresses and fix them manually in all these cases. I don't think munging the email subject is worth dealing with that.
Re: How to control access of a subversion repo subfolder via AD groups
I'll add that where we've deployed Subversion access controls, we use mod_authz_svn, and generate its contents from other sources. Not that hard to scan AD, and generate group information that can be stuffed into the access file. Eric On Wed, Jul 9, 2014 at 12:56 PM, Ben Reser b...@reser.org wrote: On 7/7/14 3:56 AM, Ankush Grover wrote: I am trying to setup Subversion authentication through Active Directory authentication and authorization through Active Directory groups.Everything is working fine but the issue I am facing is when I want to restrict access to subdirectorys of a subversion repository. For ex: there is a repo with a name ankushtest and it has a subdirectory test, now I want some users which are in AD group to be able to read or commit to subdirectory test only. This access is working fine through SVN clients like Tortoise etc.. but when I try to open the same on a browser, the user which has access only to subdirectory test is able to see the all the directorys or files under repo ankushtest. How this is working is like that, if a user types the complete url for the test directory like http://svn.example.com/src/ankushtest/test; then browser is showing the all the files directorys of a repo. In the Apache logs I see the below warning whenever I click on the url http://svn.example.com/src/ankushtest/test; and this test directory on the browser shows all the files directorys whereas this directory has only 1 file and a sub-directory in it. Mon Jul 07 14:21:47 2014] [warn] mod_dav_svn: nested Location '/src/ankushtest/test' hinders access to 'test1' in SVNPath Location '/src/ankushtest' You should only have a single Location block for your repository. That warning message is telling you as much. When you use multiple Location blocks like this then the /src/ankushtest and the /src/ankushtest/test both are Locations that point at the root of the repository. The reason you're seeing this work with a Subversion client is because the Subversion client often accesses things under the root of the repository with opaque URLs which still go through the /src/ankushtest Location block rather than the /src/ankushtest/test Location. If you want to do path based access control within the repository you must use mod_authz_svn to do this. It knows how to handle the opaque URLs and properly provide access control. Beyond opaque URLs there are also requests that provide details for child paths other than just the path the request uses in the HTTP request-line, which is all that would be matched by Location. Setting up mod_authz_svn is generally described in the SVN Book here: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir Unfortunately, using mod_authz_svn is complicated by your desire to use AD groups. The group membership that Apache httpd uses is not available to mod_authz_svn, this is just a limitation of the way Apache httpd authentication and authorization works. So in order to do what you want you need to provide the group membership information to mod_authz_svn separately. This is done by adding the [groups] section to the AccessFile. Obviously maintaining this by hand is tedious so people usually automate this. It's popular to use this tool to do that automation: http://thoughtspark.org/2009/01/20/using-ldap-groups-with-subversion-s-authz-file/ Though there are also commercial products that can do this and much more such as WANDisco's Access Control product: http://wandisco.com/subversion/accesscontrol I suspect there are other commercial products that can manage this for you as well though I'm not as familiar with their features (full disclosure I work for WANdisco). If you don't go the route of a commercial product to manage this I'd suggest that you do the following things beyond just using mod_authz_svn. * Include the SVNPathAuthz short_circuit directive in your Location blocks for SVN. This avoids running authentication/authorization processing as sub-requests for paths that aren't in the request-line but that must be accessed to service the request. The default uses much more expensive sub-requests, which while secure for any configuration are much more expensive. Almost not configurations actually need the default setting. * You mention that you're using Subversion 1.7, but Subversion 1.8 adds the AuthzSVNGroupsFile directive that permits this group data to be in a separate file from your access configuration. This should make it easier to configure.
Subversion Exception Updating
Hi everyone. An exception just happened when I execute a regular update of my local repository: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1550: assertion failed (action == svn_wc_conflict_action_delete) The exception happen after one folder was displayed as added in the update results window. After that the crush. Thanks in advance. Best regards, Gilberto Gomez
