Re: AuthUserFile not specified in the configuration
Justin Mrkva wrote on Thu, Apr 03, 2014 at 00:53:41 -0400: [error] [client ::1] AuthUserFile not specified in the configuration Apache runs as _www:_www, and the directory containing the repository as well as the repos themselves are all _www:_www 755. The htdigest file is _www:_www 644. The realm for the user matches the httpd.conf AuthName. The password is correct. Both SVNParentPath and AuthUserFile are the correct paths. Here are relevant lines from httpd.conf: LoadModule auth_digest_module libexec/apache2/mod_auth_digest.so LoadModule dav_svn_module /usr/local/libexec/mod_dav_svn.so LoadModule authz_svn_module /usr/local/libexec/mod_authz_svn.so Location /svn DAV svn SVNParentPath /Library/Subversion/Repositories SVNListParentPath on AuthName Subversion AuthType Digest AuthDigestProvider file AuthUserFile /private/etc/svnauth.htdigest Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work? (I'm suspecting /private might be unreadable by _www.) Another possibility is that httpd treats GET and OPTIONS requests differently, i.e., that some other part of the config kicks in for the latter but not for the former. Require valid-user Allow from all /Location
Re: AuthUserFile not specified in the configuration
On Apr 4, 2014, at 04:24, Daniel Shahaf wrote: Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work? (I'm suspecting /private might be unreadable by _www.) On a normal OS X system, /private and /private/etc have rwxr-xr-x permissions.
Re: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
On 03.04.2014 12:47, Philip Martin wrote: Guido Wischrop guido.wisch...@mgm-tp.com writes: I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this: svn checkout https://user:pass@server/svn/p1/trunk I get the following error immediately: svn: E17: 'https://user:pass@server/svn/p1/trunk' isn't in the same repository as 'https://user:@server/svn/p1/trunk' I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5) X64) with the same result. With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command works as expected. Is the user:pass@server scheme no longer supported? I get the same problem with trunk on Linux. I can fix it with this patch but I'm not sure I understand all the consequences. Is there any reason we should be hiding the password here? Index: subversion/libsvn_ra_serf/options.c === --- subversion/libsvn_ra_serf/options.c (revision 1584323) +++ subversion/libsvn_ra_serf/options.c (working copy) @@ -245,7 +245,8 @@ (char *)svn_fspath__canonicalize(val, session-pool); session-repos_root_str = svn_urlpath__canonicalize( -apr_uri_unparse(session-pool, session-repos_root, 0), +apr_uri_unparse(session-pool, session-repos_root, +APR_URI_UNP_REVEALPASSWORD), session-pool); } else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0) So is this considered to be a bug? Is there another workaround as using --user --password? Thanks, Guido
RE: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
-Original Message- From: Guido Wischrop [mailto:guido.wisch...@mgm-tp.com] Sent: vrijdag 4 april 2014 15:07 To: users@subversion.apache.org; d...@subversion.apache.org Subject: Re: svn: E17: 'https://user:pass@x' isn't in the same repository as 'https://user:@x' On 03.04.2014 12:47, Philip Martin wrote: Guido Wischrop guido.wisch...@mgm-tp.com writes: I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like this: svn checkout https://user:pass@server/svn/p1/trunk I get the following error immediately: svn: E17: 'https://user:pass@server/svn/p1/trunk' isn't in the same repository as 'https://user:@server/svn/p1/trunk' I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5) X64) with the same result. With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command works as expected. Is the user:pass@server scheme no longer supported? I get the same problem with trunk on Linux. I can fix it with this patch but I'm not sure I understand all the consequences. Is there any reason we should be hiding the password here? Index: subversion/libsvn_ra_serf/options.c == = --- subversion/libsvn_ra_serf/options.c (revision 1584323) +++ subversion/libsvn_ra_serf/options.c (working copy) @@ -245,7 +245,8 @@ (char *)svn_fspath__canonicalize(val, session-pool); session-repos_root_str = svn_urlpath__canonicalize( -apr_uri_unparse(session-pool, session-repos_root, 0), +apr_uri_unparse(session-pool, session-repos_root, +APR_URI_UNP_REVEALPASSWORD), session-pool); } else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER) == 0) So is this considered to be a bug? Is there another workaround as using --user --password? As far as I can tell we only really support a username in the url for svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to the lower layers and the neon library (our = 1.7 default) completely ignored this, while serf (which we use as default since 1.8) tried to use it as the hostname. I would really recommend not using a username in the url this way... You just store the password unencrypted on your disk in a place where it isn't even really used. It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly different authentication id. And as Subversion doesn't actually use the username and password from the url, they won't be updated if you ever want to change your password (or use the working copy as a different user) Bert Thanks, Guido
Working copy blocking
We are all running the latest TortoiseSVN which is build with svn 1.8.8. Attempting to add files, I got this message (retrying it, the add worked) Command: Add Error: sqlite[S5]: database is locked Error: Additional errors: Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Completed!: This is on a Windows 7 system. The working copy is on the local drive. I'm thinking it is because perhaps we use both Tortoise and Ankhsvn? What can I look at?
Re: Working copy blocking
Hi, On 04/04/14 18:13, Bob Archer wrote: [TVSN + AnkhSVN on Win7] Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Check if either client has exclusive locking configured: https://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking Andreas
RE: Working copy blocking
On 04/04/14 18:13, Bob Archer wrote: [TVSN + AnkhSVN on Win7] Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Check if either client has exclusive locking configured: https://subversion.apache.org/docs/release-notes/1.8.html#exclusiveloc king Andreas Can you remind me where the svn config file is on windows? Tortoise doesn't seem to want to open the file.
Re: Working copy blocking
On Fri, Apr 4, 2014 at 1:51 PM, Bob Archer bob.arc...@amsi.com wrote: On 04/04/14 18:13, Bob Archer wrote: [TVSN + AnkhSVN on Win7] Error: sqlite[S5]: database is locked Error: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server. Check if either client has exclusive locking configured: https://subversion.apache.org/docs/release-notes/1.8.html#exclusiveloc king Andreas Can you remind me where the svn config file is on windows? Tortoise doesn't seem to want to open the file. Open the Run dialog or the Explorer and type in %APPDATA%\Subversion Windows will resolve that variable to the right location. -- Thanks Mark Phippard http://markphip.blogspot.com/
Subversion 1.8.8 externals error
Hi, Subversion 1.8.8 returns an error when checking out or updating a working copy with the following externals. $ svn proplist -v Properties on '.': svn:externals https://github.com/SenH/sinatra-formkeeper/trunk/lib/sinatra lib/sinatra https://github.com/SenH/formkeeper/trunk/lib/ lib/formkeeper svn:ignore .bundle Gemfile.lock $ svn up Fetching external item into 'lib/sinatra': External at revision 45. Fetching external item into 'lib/formkeeper': External at revision 37. Removed external 'lib': '/var/www/thais-sander/thais-sander.be/lib' is already locked via '/var/www/thais-sander/thais-sander.be'. svn: warning: W20: Error handling externals definition for 'lib': svn: warning: W155004: '/var/www/thais-sander/thais-sander.be/lib' is already locked via '/var/www/thais-sander/thais-sander.be'. Updated to revision 122. svn: E205011: Failure occurred processing one or more externals definitions The working copy doesn't have the 'lib' folder but according to the book: The relative target subdirectories of externals definitions must not already exist on your or other users' systems Subversion will create them when it checks out the external working copy. This has always worked in 1.6.17. Any pointers?
