Re: Branching slow 1.8.11 https
On Tue, Mar 31, 2015 at 8:49 PM, Johan Corveleyn wrote: > On Tue, Mar 31, 2015 at 2:19 AM, Johan Corveleyn wrote: > ... >> I think I've found a workaround: it seems the tree walk by mod_dav is >> avoided when the request has a header Depth with value 0. I've tried >> adding >> >> >> RequestHeader set Depth 0 >> > > Apparently this workaround is specific to httpd 2.4 or higher > ( is only available as of 2.4). Since the problem also exists > in httpd 2.2.25 or higher, this might be a better way to do this: > > SetEnvIf Request_Method COPY method_is_copy > RequestHeader set Depth 0 env=method_is_copy > > This should work both in 2.4 and 2.2. > This problem and its workaround are now documented in our FAQ: http://subversion.apache.org/faq.html#dav-slow-copy -- Johan
Issue with subversion authentication
Hi, I'm having issues with SVN authenticating my users against my users file. SVN was working yesterday morning, I then created a new user account on the SVN server and created a new SVN user using the htpasswd command. Since then my subversion is no longer authenticating my users from the users file. In TortoiseSVN I am getting this error: "Unable to connect to a repository at URL 'https:...' OPTIONS of 'https:...': authorization failed: Could not authenticate to server: rejected Basic challenge" I have tried removing the new user using the htpasswd -D command but that hasn't fied the problem with the authentication. If I comment out 'AuthType Basic' then anonymous access is available, but when I commit repos in TortoiseSVN it completes with this error: "post-commit hook failed (exit code 1) with output: svn: warning: Can't open file '/etc/subversion/servers': Permission denied Authentication realm: 10830e04-d36d-4252-bd61-a1eee9982873 Username: svn: Can't read stdin: End of file found" Please can you tell me where I'm going wrong and how to fix this issue?
Re: Issue with subversion authentication
On 01.04.2015 08:58, Matthew Durandt wrote: > Hi, > > I'm having issues with SVN authenticating my users against my users > file. SVN was working yesterday morning, I then created a new user > account on the SVN server and created a new SVN user using the > htpasswd command. Since then my subversion is no longer authenticating > my users from the users file. In TortoiseSVN I am getting this error: > "Unable to connect to a repository at URL 'https:...' OPTIONS of > 'https:...': authorization failed: Could not authenticate to server: > rejected Basic challenge" > > I have tried removing the new user using the htpasswd -D command but > that hasn't fied the problem with the authentication. If I comment out > 'AuthType Basic' then anonymous access is available, but when I commit > repos in TortoiseSVN it completes with this error: > "post-commit hook failed (exit code 1) with output: > svn: warning: Can't open file '/etc/subversion/servers': Permission denied > Authentication realm: 10830e04-d36d-4252-bd61-a1eee9982873 > Username: svn: Can't read stdin: End of file found" > > Please can you tell me where I'm going wrong and how to fix this issue? Why are you creating unix user accounts in the first place? Regarding your error, check if the account user that httpd is running as has permission to read the /etc/subversion/servers file. -- Brane
branching over mod_dav 2.4.6 is O(tree) (was: Re: Branching slow 1.8.11 https)
[ moving to dev@, please remove users@ from replies ] Johan Corveleyn wrote on Sun, Mar 29, 2015 at 19:57:34 +0200: > On Sat, Mar 28, 2015 at 5:09 PM, Bert Huijben wrote: > > Httpd's mod_dav was updated in some recent version to do a full lock > > traversal on copies and moves. I think we already applied some > > optimizations, but the real fix would be that mod_dav shouldn't do > > this work (which our repos layer already does). > > > > I'm not sure which release we applied the first set of optimizations. > > > > Thanks for refreshing my memory. > > So the problem is known as issue #4531 (server-side copy (over dav) > uses too much memory) [1]. The memory usage issue has been fixed in > SVN 1.8.11 and 1.7.19 (see CHANGES), but a performance problem remains > (copy is no longer O(1), but depends on the size of the tree being > copied). That's a direct violation of one of Subversion's "old selling > points" vs. CVS: that branching / tagging is O(1). Branching / tagging > taking several minutes brings back "fond memories" from CVS' days. > > As Philip pointed out in his last comment on #4531 [2]: "This issue is > related to a change in mod_dav in 2.2.25 to fix PR54610 which > added a walk over the copy source looking for lock tokens." (also > released in 2.4.5; so both httpd 2.2.25+ and 2.4.5+ are affected -- > older httpd's won't have this problem I guess). > > Again quoting Philip: "Apache knows in advance that the walk is > redundant in cases such as Subversion's URL-to-URL copy but Subversion > cannot avoid the read access. We should attempt to fix mod_dav to > avoid the walk where possible." > > So my hope rests with Philip and others who might have the necessary > knowledge to fix this in mod_dav. It's really not acceptable that > branching / tagging (or I'm guessing also: moving a large tree with a > server-side move) takes several minutes. So, what will a mod_dav fix look like? I understand the issue is that it walks the copy source for locks. Should it stop doing that? Should it allow the backend module (mod_dav_svn / mod_dav_fs) to implement the walk in a more efficient manner — for example, adding a "Are there any locks under path X" hook that the backend module could implement? (Rather than the current design, which AIUI is the backend walks the tree and mod_dav calls "Is path X locked" for each path reported by the backend.) Daniel
Re: Issue in svn E195020
[ As an aside: this list prefers bottom-posting (i.e. putting your reply at the bottom) or inline replying, if possible. Also, plain-text is preferred, but I'll manage :-). See more below ... ] On Wed, Apr 1, 2015 at 3:36 AM, Scott Aron Bloom wrote: > Here is some more info: > > First I show the results of the svnversion, showing the mixed revision. > Then I do a svn merge (with –allow-mixed-revisions) and get the E195020 > error > Then I do an svn up > Then another svnversion still showing the mixed revision > Then finally the merge showing the problem still exists.. > > Scott > > > $ svnversion > 28594:29395S > > scott@Vader ~/sb/bps/9.0.29202 > $ svn merge --allow-mixed-revisions ^/branches/vijay/vhdlBitWidthFix_1 . > svn: E195020: Cannot merge into mixed-revision working copy [28594:29395]; > try updating first > > $ svn up > Updating '.': > > Fetching external item into 'UI\nlview': > External at revision 26116. > > Fetching external item into 'verific': > External at revision 29173. > > Fetching external item into 'tcl': > > Fetching external item into 'tcl\Install': > External at revision 23404. > > At revision 28171. > > Fetching external item into 'gmock': > External at revision 11153. > > Fetching external item into 'qtiocompressor': > External at revision 29045. > > Fetching external item into 'Licensing': > External at revision 28829. > > Fetching external item into 'tcllib': > External at revision 23595. > > Fetching external item into 'Prerequisites': > External at revision 28594. > > Fetching external item into 'libicu': > External at revision 28899. > > Fetching external item into 'libxcb': > External at revision 28929. > > Fetching external item into 'Installation\FPGALibraries': > External at revision 29142. > > Fetching external item into 'UI\QtGraphVizLib\libcgraphviz': > External at revision 28492. > > At revision 29395. > > $ svnversion > 28594:29395S > > $ svn merge --allow-mixed-revisions ^/branches/vijay/vhdlBitWidthFix_1 . > svn: E195020: Cannot merge into mixed-revision working copy [28594:29395]; > try updating first Interesting! That definitely points to externals as the likely cause of the problem. I'll note that 28594 (the first rev reported by svnversion) is the one of the 'Prerequisites' external item. So I'd start by analyzing that one a bit more. Specifically: is that a file external? If so, can you share its external definition (the value in the svn:externals property that defines it) -- feel free to strip out confidential information such as hostname of your server etc. I'm mainly interested to see in what format it's specified, if it has a peg revision, ... With that info one might be able to reproduce it on a test repository, so we can take a closer look. -- Johan
Re: branching over mod_dav 2.4.6 is O(tree)
Daniel Shahaf writes: > So, what will a mod_dav fix look like? I understand the issue is that > it walks the copy source for locks. Should it stop doing that? Yes, I believe so. mod_dav should avoid the walk when the callback result for every path in the walk is known in advance. I spoke to Ben yesterday and he said he has an httpd patch that is just about ready. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Apache Subversion 1.7.20 released
[ Followup trimmed to subersion-devel and subversion-users ] On Tue, Mar 31, 2015 at 8:03 AM, Stefan Sperling wrote: > I'm happy to announce the release of Apache Subversion 1.7.20. > > This release addresses two security issues: > > CVE-2015-0248: Subversion mod_dav_svn and svnserve are vulnerable to a > remotely triggerable assertion DoS vulnerability for certain > requests with dynamically evaluated revision numbers > CVE-2015-0251: Subversion HTTP servers allow spoofing svn:author property > values for new revisions Cool, thanks for the update! It wouldn't affect me since I use svn+ssh these days, but I'm glad for others to ge tthe fix. I've updated my public tools for building 1.7.x and 1.8.x on RHEL based operating systems to match, at https://github.com/nkadel/subversion-1.8.x-srpm https://github.com/nkadel/subversion-1.7.x-srpm I'm having difficulty building recent 1.7 releases on RHEL 5., I'll go into more detail on that in another note. I've also not pursued compiling for RHEL 7 yet, being reluctant to touch systemd if I can avoid it, but I'm going to have to learn. Nico Kadel-Garcia > For details see the advisories at: > > http://subversion.apache.org/security/CVE-2015-0248-advisory.txt > http://subversion.apache.org/security/CVE-2015-0251-advisory.txt > > Please choose the mirror closest to you by visiting: > > http://subversion.apache.org/download/#supported-releases > > The SHA1 checksums are: > > f600c68010d2fd9a23fc8c6b659099aedac12900 subversion-1.7.20.tar.bz2 > 675ac5a843e01dbb4a30d6333a809fd048c5ce0c subversion-1.7.20.zip > e861f85e9df1b5aca903aa6eda15919c454cbda5 subversion-1.7.20.tar.gz > > PGP Signatures are available at: > > http://www.apache.org/dist/subversion/subversion-1.7.20.tar.bz2.asc > http://www.apache.org/dist/subversion/subversion-1.7.20.tar.gz.asc > http://www.apache.org/dist/subversion/subversion-1.7.20.zip.asc > > For this release, the following people have provided PGP signatures: > >Bert Huijben [4096R/CCC8E1DF] with fingerprint: > 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF >Branko Čibej [4096R/A347943F] with fingerprint: > BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F >Ivan Zhakov [4096R/F6AD8147] with fingerprint: > 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 >Johan Corveleyn [4096R/010C8AAD] with fingerprint: > 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD >Julian Foad [4096R/4EECC493] with fingerprint: > 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 >Philip Martin [2048R/ED1A599C] with fingerprint: > A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C >Stefan Fuhrmann [4096R/57921ACC] with fingerprint: > 056F 8016 D9B8 7B1B DE41 7467 99EC 741B 5792 1ACC >Stefan Sperling [2048R/9A59B973] with fingerprint: > 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 > > Release notes for the 1.7.x release series may be found at: > > http://subversion.apache.org/docs/release-notes/1.7.html > > You can find the list of changes between 1.7.20 and earlier versions at: > > http://svn.apache.org/repos/asf/subversion/tags/1.7.20/CHANGES > > Questions, comments, and bug reports to users@subversion.apache.org. > > Thanks, > - The Subversion Team
SVN 1.8.10 server side configured autoprops
hello svn-server-experts, i want to define autoprops (serverside dicated) for some repos in my large SVN installation. However it have been missed out in the documentation how this is achieved. The docs rely on a "config file", but not a name to it, so i tried and make a $REPOS_NAME/conf/[repons.conf|config] - doesnt work. I add this to my serverside config: [miscellany] enable-auto-props = yes [auto-props] *.xml = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.css = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.xsl = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.htm = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.html = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.txt = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.js = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.java = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.jsp = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.cmd = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL;svn:eol-style=CRLF *.bat = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL;svn:eol-style=CRLF *.sql = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.properties = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL *.sh = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL;svn:executable;svn:eol-style=LF *.pl = svn:keywords=Date Revision Author HeadURL Id LastChangedDate LastChangedRevision Rev LastChangedBy URL;svn:executable;svn:eol-style=LF I connect svn server via DAV/HTTP, authentication is made in httpd into AD. Server version is 1.8.10 and clients are all 1.8+ (according to the servers log). In a few days i will be running 1.8.13 server-side. I hope someone will guide me into configuring this autoprop setup.. Please :) br thomas
RE: Issue in svn E195020
[ As an aside: this list prefers bottom-posting (i.e. putting your reply at the bottom) or inline replying, if possible. Also, plain-text is preferred, but I'll manage :-). See more below ... ] [ Understood... too many mailing lists.. ] On Wed, Apr 1, 2015 at 3:36 AM, Scott Aron Bloom wrote: > Here is some more info: > > First I show the results of the svnversion, showing the mixed revision. > Then I do a svn merge (with –allow-mixed-revisions) and get the > E195020 error Then I do an svn up Then another svnversion still > showing the mixed revision Then finally the merge showing the problem > still exists.. > > Scott > [SNIP] > > Fetching external item into 'Installation\FPGALibraries': > External at revision 29142. > > Fetching external item into 'UI\QtGraphVizLib\libcgraphviz': > External at revision 28492. > > At revision 29395. > > $ svnversion > 28594:29395S > > $ svn merge --allow-mixed-revisions ^/branches/vijay/vhdlBitWidthFix_1 . > svn: E195020: Cannot merge into mixed-revision working copy > [28594:29395]; try updating first Interesting! That definitely points to externals as the likely cause of the problem. I'll note that 28594 (the first rev reported by svnversion) is the one of the 'Prerequisites' external item. So I'd start by analyzing that one a bit more. Specifically: is that a file external? If so, can you share its external definition (the value in the svn:externals property that defines it) -- feel free to strip out confidential information such as hostname of your server etc. I'm mainly interested to see in what format it's specified, if it has a peg revision, ... With that info one might be able to reproduce it on a test repository, so we can take a closer look. = I did notice that... (the version being the same for Prerequisites) Here is the line from the externals definition -r 28594 ^/externals/microsoft/Prerequisites Prerequisites It is a directory, that contains the VS 2013 and VS 2008 pre-req distribution executable installers for our install creation phase. Scott
Re: SVN 1.8.10 server side configured autoprops
Hello, > i want to define autoprops (serverside dicated) for some repos in my > large SVN installation. However it have been missed out in the > documentation how this is achieved. The docs rely on a "config file", > but not a name to it, so i tried and make a > $REPOS_NAME/conf/[repons.conf|config] - doesnt work. I add this to my Huh? While the run-time client configuration uses a config file section like below, [miscellany] enable-auto-props = yes this was for the *previous* client-side autoprops feautre. You want this inside the repository tree, as versioned properties. See https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config So you would start with setting or editing the svn:auto-props property on a suitable repository path. Andreas
Re: SVN 1.8.10 server side configured autoprops
Hello Andreas+ So i have tried to read the RDC docs, but it doesnt make any sense - it tells alot about how the configuration should look, but not how to implement the feature... I realize that the clientside can still be modified accordingly, and I want to push/enforce the keyword configuration from serverside. The documentatio doesnt make any sense to me... Did you have success implementing RDC? br thomas Quoting Andreas Stieger : Hello, i want to define autoprops (serverside dicated) for some repos in my large SVN installation. However it have been missed out in the documentation how this is achieved. The docs rely on a "config file", but not a name to it, so i tried and make a $REPOS_NAME/conf/[repons.conf|config] - doesnt work. I add this to my Huh? While the run-time client configuration uses a config file section like below, [miscellany] enable-auto-props = yes this was for the *previous* client-side autoprops feautre. You want this inside the repository tree, as versioned properties. See https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config So you would start with setting or editing the svn:auto-props property on a suitable repository path. Andreas
Aw: Re: SVN 1.8.10 server side configured autoprops
Hello, > So i have tried to read the RDC docs, but it doesnt make any sense - > it tells alot about how the configuration should look, but not how to > implement the feature... To implement, set versioned properties named svn:auto-props in the repository. See help about propset, propedit commands, or the equivalent function in a non-cli client. > I realize that the clientside can still be modified accordingly, and I > want to push/enforce the keyword configuration from serverside. Set svn:auto-props properties using an svn client on a path, e.g. the root of the repository, or trunk, and commit. > The documentatio doesnt make any sense to me... Did you have success > implementing RDC? Yes. Note that you need clients capable of interpreting both inherited properties and repository-dictated config. Read: 1.8. Andreas
