Apache Subversion 1.9.0-beta1 released
I'm happy to announce the release of Apache Subversion 1.9.0-beta1. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: cbc62b682e69254f57e40da316ebb7fcf998f56e subversion-1.9.0-beta1.tar.bz2 57142f460c51f334429569757974006f275240e8 subversion-1.9.0-beta1.tar.gz 66d84c7818d05141e795ed090dba3044c880f6ca subversion-1.9.0-beta1.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 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 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 This is a pre-release for what will eventually become Apache Subversion 1.9.0. It may contain known issues, a complete list of 1.9.0-blocking issues can be found here: http://subversion.tigris.org/issues/buglist.cgi?component=subversionissue_status=NEWissue_status=STARTEDissue_status=REOPENEDtarget_milestone=1.9.0 A pre-release means the Subversion developers feel that this release is ready for widespread testing by the community. There are known issues (and unknown ones!), so please use it at your own risk, though we do encourage people to test this release thoroughly. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Release notes for the 1.9.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.9.html You can find the list of changes between 1.9.0-beta1 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.9.0-beta1/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Random Checksum mismatch on fresh checkout affecting single machine
On 1/29/15 4:40 AM, Brendon Abbott wrote: Since writing this original email, I have found that the difference between the working instance and the non-working instance is not the repository, but the client. 1.6.17 works fine, whilst 1.8.11 does not. This issue sounds suspiciously like what's described here to me (note the second warning box): http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap I'd check to see if your server has been misconfigured to modify the file contents being sent to the client. The reason you're seeing a difference in behavior with older clients is likely because the default of using skelta style updates is now the default. When an update happens via bulk update mode the file content is included in the report and the filter that is triggering with a direct request of the content does not get triggered. The behavior change here is covered in this bit of the release notes as well: http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
Re: Perl Bindings: Assertion svn_uri_is_canonical failed
On 1/27/15 10:52 AM, Stefan Sperling wrote: I suppose _Core (with leading underscore) is a private namespace. I don't know why this isn't part of the public SVN::Core:: namespace. It probably should be. It is. SVN:Core::uri_canonicalize(); _Core is the raw SWIG wrapped interfaces. Core cuts out extraneous bits of the symbols and in many cases provide a lot of help to make things behave in a more Perl like manner (in this case it's just a thin wrapper). In general if it's a in libsvn_subr then it's in SVN:Core with the svn_ prefix dropped. Unfortunately the bindings are badly maintained and documentation is almost non-existent :( See http://svn.haxx.se/dev/archive-2011-02/0544.shtml While your statement isn't entirely untrue, the link is about the Python bindings. The Perl bindings have some documentation, far more than the Python bindings. But could certainly use more and of course patches would be welcome.
Re: Perl Bindings: Assertion svn_uri_is_canonical failed
On 1/27/15 9:24 AM, Lathan Bidwell wrote: In the Perl SWIG bindings: $ctx-url_from_path I believe calls the svn_uri_canonicalize in 1.8.8, but I believe that its a secondary effect (in 1.6, it doesn't cleanse the url) $ctx-url_from_path is calling svn_client_url_from_path(): http://subversion.apache.org/docs/api/1.8/group__clnt__sessions.html#ga32b1f7f851452ec8ecc8c2d899de2b0e svn_client is dropped since $ctx is the client library object. The purpose of that function is to provide a entry URL for a node in the repository. You can abuse it to do canonicalizations (because it was poorly designed) but that's not the purpose of the API. So you should use SVN::Core::uri_canonicalize().
Re: Subversion error!
On 1/21/15 7:47 AM, Tran Ngoc Lieu, Ms wrote: Dear Mr/Ms, I meet the problem with svn as the following: 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) Could you please help me check what the problem is? how can I fix it? You're several versions behind the current version of TortoiseSVN which is 1.8.10. So I'd try that since I know we fixed some of those type of problems. I don't recall if this was one of the specific ones though.
Re: Sanity-check tool for authz file?
On 1/22/15 1:00 PM, Les Mikesell wrote: Are there any tools to help find syntax issues or mismatches in paths between an authz file and the associated repo?I just spent some time tracking down a typo that had the weird effect of some users being able to create directories that they subsequently could not move or delete. Turned out to be a path missing the leading / in a section considerably below what I thought should the relevant entry, and the log of 'reparent ' without any mention of a problem (just no commit) on the denied action wasn't very helpful. Is there a good way to avoid such problems or find them after the fact? The validate subcommand of svnauthz (1.8 or newer) or svnauthz-validate before that. Comes in the tools/server-side directory of the source distribution. You may or may not have it depending on how you're getting Subversion. An authz file with this in it: [abc/be/de] * = r Will generate this: svnauthz: E220003: Section name 'abc/be/de' contains non-canonical fspath 'abc/be/de'
Apache Subversion 1.8.11 released
I'm happy to announce the release of Apache Subversion 1.8.11. This release addresses two security issues: CVE-2014-3580: mod_dav_svn DoS from invalid REPORT requests. CVE-2014-8108: mod_dav_svn DoS from use of invalid transaction names. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: 2fe09670b21fcd7e083b10f088dedcd3252e8e16 subversion-1.8.11.tar.gz 161edaee328f4fdcfd2a7c10ecd3fbcd51c61275 subversion-1.8.11.tar.bz2 bb43d38c98d6c84197ec71d1bf4f03c6bf38d14c subversion-1.8.11.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.11.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.11.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.11.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Julian Foad [4096R/4EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC 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.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.11 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.11/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Apache Subversion 1.7.19 released
I'm happy to announce the release of Apache Subversion 1.7.19. This release addresses two security issues: CVE-2014-3580: mod_dav_svn DoS from invalid REPORT requests. CVE-2014-8108: mod_dav_svn DoS from use of invalid transaction names. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#supported-releases The SHA1 checksums are: 3681b967d1c154b2aa4ccb63984d89aedafc488b subversion-1.7.19.zip bb3cd135bbd856e7f0f2d59313f075b9bbec9848 subversion-1.7.19.tar.gz a662721a3a1da70c4b0732d0bde5008ce8873575 subversion-1.7.19.tar.bz2 PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.19.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.19.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.19.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Julian Foad [4096R/4EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC 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.19 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.19/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'
On 11/6/14 5:10 AM, Nico Kadel-Garcia wrote: Out of curiosity, do the same issues occur with gcc on a modern box? Ther'e's a lot to like about MacPorts, but I don't think it's the primary build and testing platform for Subversion. Yes gcc is going to have the same issues because the declarations he needs have been removed from svn_sorts.h These declarations have been there since 1.0. Prior to 1.0 they had names in the APR namespace, since it was expected this functionality would be moved to APR. Before 1.0 we cleaned up that namespace problem and marked them private (by documentation and by using __ in the names). Of course since they were still in a public header they are effectively public APIs. Bert noticed that there were a lot of these private APIs added to the svn_sorts.h header since 1.8 on trunk and so he moved all of them into a private header that isn't installed. This meant he moved the ones that had been there since 1.0, thus breaking any 3rd party code that depended on them. Ideally we would have never exposed these. Ideally 3rd parties would have observed the private markers and not used them. I suggested that we resolve this by restoring the long standing private APIs that had been exposed. While not adding any new APIs. If nobody objects to that suggestion soon I'm going to just do it.
Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'
On 11/6/14 8:40 PM, Nico Kadel-Garcia wrote: Isn't clang installed with MacPorts? Or is that just more recent versions of clang? Barry said in his original posting he was using clang from XCode 6.1 command line tools package, which is Apple's official distribution of a compiler toolchain for OS X. As others have mentioned to you there's no mention of MacPorts on this thread. Even then it doesn't matter what compiler is in use, the problem is missing declarations. All compilers will have the same problem.
Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'
On 11/5/14 10:49 AM, Barry Scott wrote: I have been building pysvn against the latest svn kits. 1.7.18, 1.8.10 and 1.9.0-alpha2 using the Mac OS X Xcode 6.1 command line tools, clang is the compiler not gcc. Compiling and testing pysvn against 1.7.18 and 1.8.10 works with no errors. But I get compile errors when compiling pysvn against 1.9.0-alpha2: pysvn_client_cmd_info.cpp:1383:39: error: use of undeclared identifier 'svn_sort__hash' apr_array_header_t *statusarray = svn_sort__hash( status_hash, svn_sort_compare_items_as_paths, pool ); ^ pysvn_client_cmd_info.cpp:1388:41: error: subscript of pointer to incomplete type 'const svn_sort__item_t' const svn_sort__item_t *item = APR_ARRAY_IDX( statusarray, i, const svn_sort__item_t ); ^~~ /usr/include/apr-1/apr_tables.h:141:57: note: expanded from macro 'APR_ARRAY_IDX' #define APR_ARRAY_IDX(ary,i,type) (((type *)(ary)-elts)[i]) ~^ svn_sort.h has been included. First of all in general reports about pysvn should go to the pysvn devleopers and not the SVN developers. It's a separate project which you can find here: http://pysvn.tigris.org/ Looks like Bert moved this stuff into a private header in http://svn.apache.org/r1555133 . While these have always been technically private, they have been in public headers for a very long time (see http://subversion.tigris.org/issues/show_bug.cgi?id=1644 ). In general I agree with Bert's change since nobody should be using these private APIs. In practice they have been being used. Seems to me that we should rollback the long standing private symbols in svn_sorts.h while not adding any new symbols.
Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'
On 11/5/14 12:37 PM, Mark Phippard wrote: FWIW, Barry is the pysvn developer. Ahh well then never mind my pointer to his project.
Re: Problem with subversion-perl RPMs from WanDisco?
On 9/12/14 11:54 AM, Branko Čibej wrote: On 12.09.2014 20:37, Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: Alexey Neyman sti...@att.net writes: Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the _Core.so as a dependency: I don't think that's the way it works. When Perl uses a module such as SVN::Repos then Perl itself knows to uses SVN::Core as a dependency. That causes the shared objects _Repos.so and _Core.so to be loaded. You should see that _Core.so has libsvn_swig_perl-1.so as a dependency. After a bit of testing on my machine it appears that loading SVN::Repos doesn't load SVN::Core automatically. I can reproduce your error on my system, and I can solve it by adding 'use SVN::Core' to the script. All our Perl bindings tests explicitly load SVN::Core. I'm not sure what the intent of the packaging was initially, but it appears that the cross-module dependencies aren't exposed to the module loader; so loading SVN::Core is pretty much required in any script that uses our Perl bindings. I think this is more of a mess than a bug. :) The Perl bindings have a different layout that breaks what most other bindings refer to as core into two libraries. SVN::Base (which is the raw symbols that the created by swig and is needed by every module in order to bootstrap, specifically it loads the _Module.so libraries that Alexey and Philip are talking about above.). SVN::Core (which handles some initialization and wrapping of our basic types e.g. streams and pools). SVN::Client and SVN::Wc both load SVN::Core for you. Other modules do not and their examples in their documentation show you loading SVN::Core. I'd bet that I'm the one that added the loading of SVN::Core to SVN::Client and SVN::Wc since I was trying to make them friendly to use. The other modules have never really been made friendly to users. We've done something really weird with svn_swig_pl_get_current_pool() that I haven't quiet wrapped my head around yet. But yes I agree this is a mess.
Re: unversioned properties: size limitations?
I intended to reply to your other thread given roughly the same svnversion advice that Branko has already given you. On 8/12/14 9:09 AM, Alexey Neyman wrote: 1. svnversion reports the revision of the check-out, not the revision of the last modification. Use one of the alternatives that behaves the way you want. To save retyping info I've already provided elsewhere see this: https://stackoverflow.com/questions/21447373/how-to-get-correct-svn-version-number-on-unix/21448972#21448972 For reference SubWCRev is something that comes with TortoiseSVN: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-subwcrev.html 2. svnversion does not provide the $Date$ information. Patches welcome as always. If you don't want to write the patch you can always ask for it. 3. svnversion won't report anything on 'svn export'-ed sources. Your properties won't be available either. If you script the export then you know what the revision you're exporting is and can determine the information by simply doing `svn log --limit 1` on the same target (path and revision) as you exported. In order to make sure there are no changes between the export and the log if you're not using a revision number you'll probably want to look up the last changed revision using something like the log command given above and then export that revision. All that would be handled if there were a way to modify a transaction being committed :) As Branko has pointed out if you have a mixed revision working copy even your solution doesn't work because you don't necessarily have a state that ever existed in the repository. svnversion exists partly to help resolve that situation. It's difficult to give advice beyond this because I have no idea what language you're working in, what your build system looks like, what you're actually shipping (source or binaries), etc... As I urged you before, you'd be better off asking on this list for advice to solve the problem you're trying to solve than asking about problems you're having with the solutions. This is not an uncommon problem people need to solve. It gets discussed periodically. There are no perfect solutions. See X-Y Problem: http://mywiki.wooledge.org/XyProblem
Re: unversioned properties: size limitations?
On 8/12/14 9:31 AM, Branko Čibej wrote: For a start, this would require a major change in the wire protocol, where the server would, as a response to a successful commit, report any additional magic changes to the client. The problem with this is that it is error prone; the response may never arrive, for any number of reasons. Therefore, the client could not mark commtited items up-to-date until and unless it received the response. Since at least the DAV protocol is stateless, this implies all sorts of complications and the introduction of intermediate states in the working copy. In short: yes, it'd be hard. Ignoring all that... There's a better reason why it won't happen. Subversion clients before whatever version we add it to won't support it. Which leaves those clients with stale caches. You'd have to disallow it with older clients or just ignore the stale cache problem. I frankly do not see the community accepting a change that ignores such a huge problem with old clients. This is the type of change that in my opinion would require a major bump, which is unlikely to happen and even more unlikely to happen for this.
Re: unversioned properties: size limitations?
On 8/12/14 12:26 PM, Alexey Neyman wrote: Please consider these questions closed. For the 'last changed rev/date' I'll modify the 'svnversion -c' and will submit a patch to support reporting the dates as well (hopefully, it can then be applied to 1.8.x branch as well) and for the caching the results of file analysis, I'll use a post-commit script (since not performing that action does not compromise the integrity of the project in the repository). This isn't something we can backport. We don't add features on release branches. But 1.9.x is wrapping up soon, so if it turns out to be simple there's a chance it could make into a release there. Otherwise it'd have to wait until 1.10.x.
Re: unversioned properties: size limitations?
On 8/12/14 7:02 PM, Alexey Neyman wrote: Isn't that the same kind of change that happened with version 1.5 and mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A capability reporting was added, and a server can check that only mergeinfo-capable clients can start a commit. Same here, if a repository administrator wants to have pre-commit scripts that modify a transaction, he'd better check the clients' ability to handle a change to be applied to WC in server's response. If a server admin changes a transaction and the commit came from an old client then the working copy is potentially broken. If an old client doesn't know about mergeinfo it doesn't have access to that new feature. New clients lose awareness of any merges committed by the old clients but neither side is really broken. You just may be inconvenienced when merging. I think there's a huge difference there.
Apache Subversion 1.8.10 released
I'm happy to announce the release of Apache Subversion 1.8.10. This release addresses two security issues: CVE-2014-3522: ra_serf improper validation of wildcards in SSL certs. CVE-2014-3528: credentials cached with svn may be sent to wrong server. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: d6896d94bb53c1b4c6e9c5bb1a5c466477b19b2b subversion-1.8.10.tar.bz2 8e1e1e5fd97c3f575a81d66232c62dc902257a17 subversion-1.8.10.tar.gz 963637c9aac7f50b1b8d10a8918c57a88fb6844d subversion-1.8.10.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.10.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.10.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.10.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 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 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC 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.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.10 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.10/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Apache Subversion 1.7.18 released
I'm happy to announce the release of Apache Subversion 1.7.18. This release addresses two security issues: CVE-2014-3522: ra_serf improper validation of wildcards in SSL certs. CVE-2014-3528: credentials cached with svn may be sent to wrong server. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#supported-releases The SHA1 checksums are: 09fa636f2c59a5a4bc965def814645a2841e1b91 subversion-1.7.18.zip 96873512eeb196e5ba6435fbffb24ba284bfcf84 subversion-1.7.18.tar.gz 56bd2b413950c916642bb4c280690da875d3c745 subversion-1.7.18.tar.bz2 PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.18.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.18.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.18.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 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 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC 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 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.18 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.18/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: bug with autoindex on Apache 2.4 when loading SVN modules
On 8/2/14 12:17 PM, Gibson, Brian (IMS) wrote: I have found that if I have these two configuration statements on my Apache server, I can no longer use auto index. LoadModule dav_svn_module /usr/local/subversion/modules/mod_dav_svn.so LoadModule authz_svn_module /usr/local/subversion/modules/mod_authz_svn.so If I remove those two modules, auto index works perfectly. Has anyone else seen this? Is there a possible work around? I’m using Apache 2.4.10, subversion 1.8.9, Apr 1.5.0, Apr-util 1.5.3, and Serf 1.3.6. I’m not sure if there is any more information I can give you that would be helpful. Best thing you can provide is an example configuration and explaining what you expect it to do and what it is doing. Ideally you'd make the configuration as simple as you can while still demonstrating the issue. That said I wouldn't be surprised if what you're seeing isn't related to this: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap But you haven't provided enough information for me to say for sure.
Re: Short-urls impossible with WebDAV Pass Thru
On 8/7/14 8:50 AM, Stefan Sperling wrote: Oh geez... the cobwebs... I honestly don't recall, but I strongly suspect that it has something to do with how the mirroring filters work. These things do essentially a global search-and-replace on the request and response bodies and headers, transforming strings in requests that look like the path portions of the master URL into those that match the path portions of the slave URL; vice-versa in responses. And the protocol doesn't speak in terms of fully qualified URLs -- within the bodies, it's just the path portions. I recall running into problems when asking the C code to do a global search and replace of either or / with something else. :-) Now, that check I added might be something we could relax iff the slave URL's path portion is likewise empty -- meaning you're mapping between two server roots. The mirror code does detect the situation where the search-and-replace would be a noop (because the strings are identical), and avoids filtering at all in such situations. Of course, as you know, having matching path portions here is the *only* safe way of using the mirroring code at all. Yet, to my knowledge, we still don't require our users to set things up that way. To add to this. I wouldn't ever recommend running Subversion at the ServerRoot. There are all sorts of edge case bugs that have come up over the years when doing that. I have no doubt there will be other bugs in the future related to this. Our test suite does not test this scenario. For example there was this situation not that long ago: http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
Re: Ran svn revert but files are still modified
On 7/31/14 6:51 AM, OBones wrote: Well, browsing through history, I found out that the svn:special property with value * was added to the file at the same time that its content changed from 20M to 79K which appear to be the exact beginning of the original file. I'm not sure how this happened but reverting those changes made the sticky modified status go away. Thanks for all of you that provided suggestions. svn:special with any value (though we prefer it to be just '*') means that the file is a symbolic link. Subversion on Windows can't actually turn these into something like links (primarily because the equivalent functionality takes special permissions on Windows). The way symbolic links are implemented in SVN is that the property is set and then the contents of the file are set to something special. Clients on platforms where symbolic links are supported transparently convert these into real links. On platforms like Windows it shows up as a regular file with the contents that the client uses to know how to create the link. I'm still not quite clear on how you got things into the state that you did, but I'd thought I'd add this information here in case someone happens to find this thread searching.
Re: illegal filename under windows
On 8/1/14 12:05 AM, Pflästerer, Karl wrote: Because are not allowed under Windows in filenames svn could not create the file. But they also couldn’t cleanup the WC. The working copy was completely broken (für svn) and they had to checkout everything new. It'd be helpful if you could post the error messages that you received when you tried this as well as the version information that Ryan already asked for.
Re: svn usage map
On 8/1/14 12:26 PM, Mark Phippard wrote: If you want to know who is accessing your SVN repository you need to be using the Apache server option and then you need to mine the Apache access logs for this information. A bit more of a pointer here but there is the high-level logging feature of mod_dav_svn which may be more useful than just straight up access logs (since those log the DAV protocol methods and not really what commands the client is using). However, utilizing this feature lets you get logs that are more likely what you probably want. Note that generally this feature depends on clients telling the server what they're doing and it's entirely possible for a client to be modified to lie. See this section of the SVN Book: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging
Re: http-request PUT
On 7/24/14 12:44 AM, merch store wrote: i thought the same, but i use the youngest revision i get from the OPTIONS the SVN-Txn-Name which i get from the POST request and need for the PUT is the same revision as the youngest revision is it possible that i need the revision in which my xml was edited the last time? or that the url for POST and PUT needs the following revision of the youngest revision? but if thats the case then i won't get the SVN-Txn-Name from the POST request, because it returns only the Txn-Name of the youngest rev not of the next rev I think you're confusing two different bases here. The transaction has a base, which happens to be included in the transation name (though this is an implementation detail and isn't something a client can count on). The base of a transaction is always the youngest revision at the time the transaction is created. However, the base of the file you're sending with PUT is not necessarily the same as the transaction base. Instead it should be the revision of the file that you modified to get the version you're about to commit (i.e. the version of the file that you checked out). If that happens to be the same as the transaction base that's fine. But in a busy repository it's likely not to be. You can mostly skip the out of date checks (i.e. you want to commit your new file regardless of what's there and possibly lose other changes people have made) you can do so by providing the youngest version you got from OPTIONS in X-SVN-Version-Name for the file, sending full text and not a delta, and NOT sending the X-SVN-Base-Fulltext-MD5 (since you may not even know it and it's not required). However, even this can fail with an out of date check if someone else happens to commit a change to that file while you're transmitting your commit. It'd probably be a lot easier to help you if you explain precisely what you're working on. Your description of want to do a checking from an html-site is far from being specific. You mention implementing a checkout but it's not clear if you have a working copy (I'm guessing not since doing that is far more complicated than the protocol). If you don't have a working copy then you need some way of storing the base information (something a working copy does for you) if you don't want to just overwrite whatever is in the repository. This however seems like an X-Y problem to me.[1] Unless your project absolutely can't do it I'd also strongly suggest that you use our library (or bindings) to do the actual communication with the server. We also have the svnmucc utility which is intended to support commits that aren't being done out of a working copy. If nothing else it may be instructive to you as to how to handle this. [1] http://mywiki.wooledge.org/XyProblem
Re: Problems downloading source distribution
On 7/20/14 7:34 PM, Ian Grant wrote: I am trying to get subversion source. I followed the download links from http://subversion.apache.org/download/#supported-releases which point me at the mirror http://mirror.nexcess.net/apache/subversion/subversion-1.7.17.tar.bz2 I have downloaded both this and http://mirror.nexcess.net/apache/subversion/subversion-1.7.17.tar.gz, the former twice, and all three files have been corrupted somehow, though I got no error from FireFix 30.0, which did the download. I've downloaded them myself from that mirror and they come down fine and validate both with SHA1 checksums and the GPG signature. Sounds like some sort of local issue or an issue between you and the mirror. I'd suggest trying a different mirror. There is a dropdown box at the top o the download page where you can choose a mirror (or reloading the page will get you a random mirror).
Re: Probable bug: writes commit messages to read-only trees
On 7/17/14 10:16 AM, Caitlin Matos wrote: I attempted to add and commit a file to a new repo that I *should* have read-write access to. I still can't figure out whether I really have RW or RO access, but I think this is irrelevant. When I committed the file, I received the following message: Adding watchfiles/xdg-utils_1.1.0~rc1+git20111210.watch Transmitting file data . Committed revision 289. Warning: post-commit FS processing had error 'attempt to write a readonly database'. This means the rep-cache.db file is not writable by the server. You should report this to the server admin. I would guess that the $REPO/db/rep-cache.db file has the wrong permissions on it. The rep-cache.db is an optional add-on to the repository. It's used for de-duplication when commiting identical content that's independently created (i.e. not via svn cp). If the file is deleted or missing the worst that can happen is that the repository ends up taking up more space than it would otherwise. Specifically it's a simple key/value set with the key being the SHA1 hash of the data and the value being where the representation of that can be found. You don't mention what version of Subversion is on the server (and I don't really expect you to know since it sounds like you're not running the server). However, newer servers should report something like this now: Warning: post commit FS processing had error: Couldn't open rep-cache database I couldn't find exactly the error message you provided and this baffled me for a bit until I duplicated the situation I expected and saw the message contained (post commit as opposed to post-commit). When reporting issues it is very helpful to make sure you transcribe the output exactly. When I browsed the repo online, I can see that the history has indeed changed, and it references a file that does not exist on the server. Are you sure about that? Because the output you posted above is not consistent with that. Your commit should be stored in a complete and accurate way. This is very odd behaviour. SVN is writing to the log, THEN attempting to upload the file, and if the upload fails, the log persists. Suggested behaviour: one of: 1) determine RO/RW access before writing commit to log; refuse to commit if RO 2) keep as is, but when RO error encountered, undo the commit. Subversion already works this way. We build up a transaction (which requires write access) and then commit the transaction. The Adding line in your output is from when the structure of the tree is being sent. Transmitting file data, is from when the actual contents of the file is sent. Committed revision 289, is when the transaction is converted to a new revision. If anything fails during the creation of the transaction or the conversion to a revision then no change takes place. The rep-cache write has to happen after the commit because representations of content aren't permanently stored in the repository until the commit completes. Since the rep-cache isn't required for normal operation this doesn't present a problem, failed modifications of the rep-cache.db simply display the warning you saw.
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: Where to get apache httpd Windoze binaries compatible with alagazam?
On 6/26/14 1:42 AM, Cooke, Mark wrote: Sorry, I may be wrong, I tried quite a few packages yesterday. I have a memory of the package reporting that it was going to install python 2.5 (whilst I already have 2.7.7 installed). I will try it again but not today, unfortunately... My notes from late last year tell that the WANdisco Windows installer has swig-python that depends on Python 2.7.2. Things may have changed since then though. I'll look as well but like you probably not today.
Re: Where to get apache httpd Windoze binaries compatible with alagazam?
On 6/25/14 3:49 AM, Cooke, Mark wrote: I have investigated WanDisco (no bindings) and CollabNet (won't even install without Java, not allowed). Note I need offline installers, so that excludes (I believe) tools such as userSVN... The WANdisco Windows installer has swig-python and JavaHL bindings the last time I looked. Are you sure it doesn't?
Re: New subversion bug?
On 6/16/14 8:26 PM, Croft, Joe wrote: Thank you, but it would be nice to have a command line option to turn off this feature. Seems like a reasonable suggestion. I'd suggest --no-target-directory which mirrors the GNU cp option that provides this functionality. Don't think the various Windows commands have an equivalent.
Re: Getting a diff file from java svnkit
On 5/18/14, 5:22 PM, ajaydeo wrote: I need to get all the changes that happened in a particular svn revision. In short, I have revision number and URL to the svn To accomplish it, from command line I use following command: svn diff -c 1593651 http://svn.apache.org/repos/asf/lucene/dev/trunk Now, same thing I need to get through Java SVNKIT. SVNKit is not part of the Apache Subversion project. So you're unlikely to find much help here. They have their own mailing lists so you should ask there: http://www.svnkit.com/support.html#mailing-lists
Re: how to manually check the MD5 of a file in SVN
On 5/19/14, 6:30 AM, nisha wrote: I get a Base checksum mismatch error on commit operation. Not sure what could have changed (or not changed) the hashed file or what could have altered the MD5 during transportation (check out time or check in time). While checking out, the working copy did not receive the original checksum but an altered one; Working copy is not in sync. While checking in, the server did not receive the original checksum or file but an altered one; Does anyone knows how too manually check the MD5 of a file in SVN ? So that i can make sure than after a checkout and before a checkin MD5 are identical in the working copy and the server. Can you post the exact error message you're getting?
Apache Subversion 1.7.17 released
I'm happy to announce the release of Apache Subversion 1.7.17. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#supported-releases The SHA1 checksums are: f8e8df7439266eee425cf9f2efb18dfe9e6f5dd0 subversion-1.7.17.tar.gz 6950f6cae83992f9df440d828835646051106d15 subversion-1.7.17.tar.bz2 14d344948efd2822366c8fc886250262f9141e15 subversion-1.7.17.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.17.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.17.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.17.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Julian Foad [4096R/4EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC 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 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.17 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.17/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Checksum in --xml for svn info repo_file
On 5/12/14, 2:49 PM, Dan Ellis wrote: When performing an svn info on a local working copy, I can see the file's checksum (sha-1 specifically), but this doesn't work on repositories. It would be really nice and save some bandwidth if I could simply compare checksums versus performing a diff. Is there support in the SVN server API that supports this property? If so, is there any interest from the developers to add this xml tag? The server doesn't actually expose that information to the client, though we could do so. However, the XML output probably wouldn't look the same because the existing output is extra output from the working copy data. So the output from the server wouldn't belong in wc-info. Given that 1.8 solves your --summarize issue, unless there's some other use case for this I'm not sure it's worth exposing. You're of course welcome to send in a patch. You basically just need to expose it as a live property (to use the terms from DAV), which the client could request specifically or just get when requesting all such properties as we do when doing info over DAV. With svnserve the stat command would need to start returning it. To retrieve the data you'd use svn_fs_file_checksum().
Apache Subversion 1.8.9 released
I'm happy to announce the release of Apache Subversion 1.8.9. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: 424ee12708f39a126efd90588083dcc4eeaf subversion-1.8.9.tar.bz2 c9cb166654862ee0eb6b363a2de71d72514c69ca subversion-1.8.9.tar.gz 3f8d0621794befd1ad2917dc83ea9782b50b6426 subversion-1.8.9.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.9.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.9.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.9.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF 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 Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.9 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.9/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: SVNCacheRevProps and other performance tweaks.
On 5/14/14, 12:06 PM, Ben Reser wrote: Actually I think it's more that you really must have this enabled if you have revprop packing turned on. I can't think of a reason you don't want this turn off other than desiring to reduce resource usage at the cost of slower performance. Oops double negative. I meant I can't think of a reason you don't want to turn this on...
Re: SVNCacheRevProps and other performance tweaks.
On 5/14/14, 10:11 AM, Terry Dooher wrote: SVNPathAuthz – Currently ‘On’. To my understanding, the value ‘short_circuit’ will prevent any other path-based authorisation being used for requests. I’m running Apache2.4/mod_dav_svn, with local Basic Auth and local Authz files. No network drives or other auth methods are configured for the server, which is dedicated to svn. Would short_circuit save me any processing time in this scenario or is it only useful for people with LDAP or other auth systems that might slow down request processing? This setting controls the handling of authorization for what I refer to as secondary paths. I.E. paths that are accessed other than the path that gets directly accessed as the uri in the request line. A good example of this a 'svn log' request will check authorization for each file modified by a revision when returning the log data for that revision in order to determine how much information to return (some or all of the revision properties are omitted based on this). on (default): This causes the authorization check to generate a sub-request. This means that a GET request for each of the secondary paths described above is generated. This request is re-run through all of the authentication and authorization processing. Usually this setting (despite being the default) is not what you want. It is however the safest setting from a security perspective. Unless you are using a httpd authorization module that also looks at paths this added overhead does nothing for you. LDAP and other external authentication makes the performance of this worse, however it's still a measurable performance delay without such systems. off: The secondary path setting does not run. It presumes if you have access to the URI in the request-line you have access to all paths. This is the setting you want if you are not using mod_authz_svn (i.e. not using path based authorization). short_circuit: The secondary path checks do not generate sub-requests but rather short circuit the httpd authentication/authorization infrastructure and directly as mod_authz_svn. This has significantly less overhead, while being as secure as on provided that the only authorization module that is path aware is mod_authz_svn. If you're using authz unless you have an extremely rare case you want this setting. In your scenario you want to use short_circuit. SVNCacheRevProps – Currently ‘Off’. I’m told that it “should only be enabled under the conditions described in the documentation”, but I can’t find any reference to it in the source or the 1.8 book, yet. What are the conditions in which it should be used and what happens if I use it outside those conditions? Do I risk DB corruption or is it only of benefit in specific scenarios? Actually I think it's more that you really must have this enabled if you have revprop packing turned on. I can't think of a reason you don't want this turn off other than desiring to reduce resource usage at the cost of slower performance. The documentation in question is the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#revprop-caching http://subversion.apache.org/docs/release-notes/1.8.html#revprop-packing SVNInMemoryCacheSize – Just want to confirm this one: Is the overall server memory footprint (CacheSize*No. of worker processes) under mod_dav_svn? I’m using the prefork mpm (some minor PHP admin scripts on the box), and typically have 20-80 running child workers active. Bumping this up 256kb or 1MB would have a negligible effect, if this is the case. First of all you probably want to read the 1.7 release notes on performance tuning: http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning Yes the amount of memory footprint of the cache (there will still be more memory used for other uses by the server) will be CacheSize*No. of worker process. Since the memory caches are per-process we do not recommend using prefork with Subversion, but rather suggest that you use worker or event MPMs. With the worker or event MPMs you are able to share the cache between the threads within the same processes. This allows you to set a larger cache size since you'll have fewer processes and more of the threads will gain access to the cache, making it to be more effective. I'd suggest you run the PHP in a separate instance of httpd or on a separate machine. It's going to be difficult to tune httpd for Subversion with these other uses in the same httpd processes.
Re: svn diff --summarize question
On 5/13/14, 10:57 AM, Ben Reser wrote: This appears to be a bug. It happens when you use one wc target and one server target. It doesn't appear on trunk, trying to track down where we fixed it and see how easy it would be to backport to 1.8.x. Looks like it was fixed with r1569804 on trunk. I don't think this was a deliberate change, but was more of a side effect of the change. I don't think this change is a particular candidate for backporting. But we probably can determine why this is broken in 1.8.x and fix it.
Re: svn diff --summarize question
On 5/13/14, 10:38 AM, Dan Ellis wrote: I am actually running SVN 1.8.5 on a windows 7 box. I tried removing the --new/--old to see if that would cause issues, but no avail: c:\Project_files\sandboxsvn diff --ignore-properties c:\project_files\sandbox\.txthttp://svr/repo/.txt@3813 --summarize D C:\project_files\sandbox_v2\.txt A C:\project_files\sandbox_v2\.txt I may try upgrading to 1.8.8 if you think there have been any changes since 1.8.5 in this area. This appears to be a bug. It happens when you use one wc target and one server target. It doesn't appear on trunk, trying to track down where we fixed it and see how easy it would be to backport to 1.8.x.
Re: svn diff --summarize question
On 5/12/14, 2:36 PM, Dan Ellis wrote: I'm trying to diff the contents between of a local working copy file to a file in the repository (I really just need a yes/no answer). This file happens to be identical in content, but they do not share the same ancestry (unrelated nodes). When I do a diff with no --summarize option, I get what I expect, namely no output: c:\Project_files\sandboxsvn diff --ignore-properties --old=c:\project_files\sandbox_v2\.txt --new=http://svr/repo/foo.txt@3813; c:\Project_files\sandbox When I add the --summarize argument to the command line, I get the following: c:\Project_files\sandboxsvn diff --ignore-properties --old=c:\project_files\sandbox\.txt --new=http://svr/repo/.txt@3813; --summarize D C:\project_files\sandbox\.txt A C:\project_files\sandbox\.txt From reading http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.diff.html, it looks like the behavior I'm seeing is similar to the --notice-ancestry flag: By default, svn diff ignores the ancestry of files and merely compares the contents of the two files being compared. If you use --notice-ancestry, the ancestry of the paths in question will be taken into consideration when comparing revisions (i.e., if you run svn diff on two files with identical contents but different ancestry, you will see the entire contents of the file as having been removed and added again). How can I get the --summarize behavior to only look at file contents? I fee like I might be missing something obvious. I suspect you're using 1.7.x or older. The summarize feature was entirely rewritten in 1.8.x and works for the scenario you describe. We know that --summarize has issues in 1.7.x and older (and I spent a lot of effort trying to fix some of the cases). Example using 1.8.9 (this isn't out yet but it should work in 1.8.8): $ svnadmin-1.8 create repo8 $ svn-1.8 co file://$PWD/repo8 wc8 Checked out revision 0. $ cd wc8 $ echo something foo $ svn-1.8 add foo A foo $ svn-1.8 ci -mm Adding foo Transmitting file data . Committed revision 1. $ svn-1.8 rm foo D foo $ echo something foo $ svn-1.8 add foo A foo $ svn-1.8 diff foo $ svn-1.8 diff --summarize foo $ svn-1.8 diff --summarize --notice-ancestry foo D foo A foo One thing you may notice is I don't have to use --new and --old because 1.8 can do summarize against paths just within the working copy now (I'm guessing that your --old is your BASE for your wc). So I suggest that you upgrade to 1.8.x.
Re: svnmucc and line endings
On 5/2/14, 3:24 PM, Dan Ellis wrote: svnmucc currently only supports linefeed (LF, \n) line endings and complains about window's style carriage return, linefeed (CRLFs, \r\n) with: Error: svnmucc: E125005: Cannot accept non-LF line endings in 'svn:log' property This is inconsistent with the svn command line that allows both but requires consistency. Is there any consideration of supporting both styles? Not supporting \r\n causes some scripting pain to clean up the file to the single format. Done on trunk in r1592148 and r1592150. For what it's worth it is also inconsistent with svnmucc since when SVN_EDITOR is called to retrieve the log message it handles line ending normalization. Thanks for the request.
Re: Subversion Windows Performance compared to Linux
On 4/28/14, 8:41 AM, Les Mikesell wrote: There's no concurrent access happening - just home directories where a user will be working on one machine or another - which is mostly transparent to normal applications.. Should there be a difference if they work on the server hosting the exported partition or will it still be slow due to locking? It will not be slow in that scenario. I have my working copies on NFS to make it easy to use a local editor but run some commands on the server where they are mounted from. Branko, is just warning you not to run concurrent operations from both the NFS host and NFS clients as that is more likely to allow the assumptions about file system atomicity to be violated that Subversion depends on. In theory what you're saying is safe, but in practice I think it's a lot harder. It'd be very easy for a user to forget and run commands in two places.
Re: Query about mercurial to svn migration
On 4/26/14, 12:14 AM, narendra agrey wrote: I have got a task of migrating code base from Mercurial to SVN. I had tried 'hg convert and it starts working upto few revisions. At one point, it fails with statement: svn error: file doesn't exists. I didn't recall the error code but there was one. What does it mean and how can it be resolved? You ought to ask this question of the Mercurial folks. It sounds like an error we're producing but we don't really know the context of how their 'hg convert' command is getting that error. I'd have to tear about their code to even begin to try and figure out possibly where it's coming from. If you're going to ask for help with an error, it's best to provide the full and exact error messages you're getting, including any error codes. Providing less than full information just makes it harder to help you and thus decreases the chances of you getting any help.
Apache Subversion 1.9.0-alpha2 released
I'm happy to announce the release of Apache Subversion 1.9.0-alpha2. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: c1de8633db4d8bc4b3145fec51b4079ca560f2a3 subversion-1.9.0-alpha2.tar.bz2 bfbe16a6820d78bf124b779e5c8f641cd9fcc343 subversion-1.9.0-alpha2.zip 2f563294e26d0ec806eef01f2e9e9231cafe3508 subversion-1.9.0-alpha2.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 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 Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD 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 This is a pre-release for what will eventually become Apache Subversion 1.9.0. It does contain some known issues (this list is not exhaustive): * Several issues with FSX (it is still experimental after all). * svnserve SASL support is broken. A pre-release means the Subversion developers feel that this release is ready for widespread testing by the community. There are known issues (and unknown ones!), so please use it at your own risk, though we do encourage people to test this release thoroughly. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. In this particular case, since many of the changes have been to the repository formats and this is only an alpha it is highly likely that incompatible format changes will be made before the final 1.9.0 release. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. With all the warnings given, we would especially like feedback on the following: * New 'svn auth' subcommand. * New reverse 'svn blame' functionality (-r M:N with MN). * Improvements to the interactive conflict resolution menus. * FSFS format 7. If you have any thoughts about the changes made in 1.9.0-alpha2 we would really appreciate your feedback (even if they are not about the above things). Getting user feedback this early in the development process provides us an opportunity to make significant changes we otherwise would not make with a release candidate. Feedback on 1.9.0-alpha2 should be directed to the users@subversion.apache.org mailing list. Release notes for the 1.9.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.9.html You can find the list of changes between 1.9.0-alpha2 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.9.0-alpha2/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
On 4/12/14, 1:30 AM, Thorsten Schöning wrote: Are you sure about that? From my understanding it is necessary that data passes OpenSSL's memory to get retrieved because it implements it's own malloc. I had the feeling that in case of heartbleed only sending passwords over http would have been the more secure way because in that case they wouldn't have been retrievable because they never passed memory allocated using OPENSSL_malloc() at all. No that's not accurate at all. The malloc implementation doesn't matter at all, the process can read memory that's allocated by any memory allocator. Ultimately all of them have to use the same kernel interfaces to request the memory. The requirements are that the memory be allocated in a larger memory address than the memory being used for the heartbeat feature and that it be within 64k of that memory space. With memory fragmentation and a lot of requests just about anything can be retrieved.
Subversion and Heartbleed
As you may have heard in the news OpenSSL has had a significant security vulnerability [1] [2]. Subversion by way of several of our dependencies uses OpenSSL. On the client side the Neon and Serf HTTP libraries can use OpenSSL (Neon can also use GNUTLS, which is not vulnerable to this issue) and on the server side Apache HTTP Server and Cyrus SASL can use OpenSSL (though Cyrus SASL's use of OpenSSL is not vulnerable). As a result it is important to make sure that the OpenSSL version being used with Subversion is not vulnerable. It is impossible for the Subversion project to provide vulnerable version information for Subversion since if you are vulnerable depends on the OpenSSL used at build and/or run time. We do not publish binaries, so you should consult with your binary provider to make sure you are not vulnerable. If you've built your own version of Subversion you should check which version you have built against and/or are using at runtime. This specific issue lies in the implementation of a feature of the SSL/TLS protocols. Apache HTTP Servers running mod_ssl to provide SSL/TLS are vulnerable. While svnserve does support encryption via Cyrus SASL, and Cyrus SASL does use OpenSSL to provide the encryption algorithms, it does not use it to implement the SSL/TLS protocols. This means that svnserve is not directly vulnerable. However, you can use the svnserve over tunnels and those tunnels may be vulnerable. For instance stunnel implements the SSL/TLS protocol and does so via OpenSSL. SSH based tunnels are unaffected as they do not use the SSL/TLS protocols. If you're using some other tunnel not mentioned here you should check with the developers of that tunnel for details. It is important to understand that this vulnerability is not specific to the server side. Clients can be vulnerable to malicious servers using the same attack against clients. So care should be taken to ensure that clients are not using vulnerable OpenSSL versions as well. The unfortunate consequence of this vulnerability is that server or client memory may be exposed to the other side of the connection. This has the possibility of exposing private information that the other side of the connection should not have. Within the context of Subversion that means authentication information, details about working copies, data from other clients, private keys used with public key encryption, etc. As a result of the above potential data disclosures, after you have upgraded to non-vulnerable versions of the software, you may want to take additional actions including revoking and reissuing SSL/TLS server and client certificates and resetting user passwords. It is understood that retrieving private keys to certificates may be very difficult, but still possible. Other data may be much easier to retrieve. As such, if these steps are necessary are largely a matter of your risk tolerance. If you are using HTTPS to access your Subversion repositories and do decide to revoke your certificates you should understand that at current Subversion does not support rejecting revoked certificates that would otherwise be trusted. Our HTTP libraries (Neon and Serf) which we depend on for this sort of functionality do not currently provide support for providing an external CRL (Certificate Revocation List), retrieving CRLs from a URL in the certificate, checking certificates via OCSP (Online Certificate Status Protocol) or handling an OCSP response that has been stapled to the TLS handshake. In the meantime, you can disable trusting certificates based on trust in the Certifying Authorities to avoid accepting revoked certificates. To do this you will want to make some configuration changes in your server config file for Subversion (usually at /etc/subversion/servers, ~/.subversion/servers, or %APPDATA%\Subversion\servers, see [3] for more details). Set ssl-trust-default-ca to no and remove the ssl-authority-files setting. By doing this Subversion will prompt for all certificates giving you details on the certificate and a fingerprint. You will then have the opportunity to accept the certificate temporarily or permanently. Server admins should let their users know the fingerprints of the correct certificates. This is similar to the manner in which SSH handles validating they are talking to the server they expect to be. If you have already trusted certificates that are now revoked you will also need to remove them from your authentication store for Subversion. This will be stored under ~/.subversion/auth/svn.ssl.server or %APPDATA%\Subversion\auth\svn.ssl.server. You can delete the entire directory to remove all accepted certificates or just delete specific files within the directory to remove just those certs. The files are simply text files containing some data, you should be able to read them to locate the specific keys you which to remove. We realize that the handling for revoked certificates is far from ideal at this time.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
On 4/10/14, 9:53 PM, Nico Kadel-Garcia wrote: I was just realizing that no one has mentioned it here: For anyone running HTTPS based Subversion servers, they should really take a good look at whether their web server is vulnerable to the HeartBleed security problem in OpenSSL. There are various good write-ups about it, but even an internal website vulnerable to these hacks could apparently have usernames and passwords stolen by a zombied or rootkitted host inside your network. So strongly consider updating *all* your websites to avoid the bug, and other bugs, and strongly consider your password management and expiration procedures for vulnerabilities that may have been exploited any time in the last two years. http://www.theatlantic.com/technology/archive/2014/04/how-to-check-if-a-site-is-safe-from-heartbleed/360417/ For what it's worth we're preparing specific advice for admins (so much as we can), but it is taking some time to complete largely because we lack much in the way of handling revoked certificates. I hope to have something up later today on the users@, dev@ and announce@ lists.
Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers
On 4/11/14, 12:52 PM, Nico Kadel-Garcia wrote: Do you have a pointer to that? It's a reasonable claim, I'd just not seen anything for verifying it or testing against HTTP sites that have HTTPS enabled, perhaps even with HTTPS only accessible behind a closed firewall for administrative user Apache HTTP Server can respond to multiple ports, some of which may be SSL enabled and some of which that many not. The same processes are used for either. As such even if you only have your Subversion repository running over HTTP, if you have SSL enabled for some other purpose, your Subversion related data in memory might be exposed.
Re: SVN client SSL CRL configuration
On 4/9/14, 8:56 AM, msk...@ansuz.sooke.bc.ca wrote: I'm not subscribed to the list and would appreciate a cc: on any replies. I run a Subversion server accessible through Apache HTTPS, and several clients that connect to it, all under Linux, and I run my own CA (certificate authority) to issue SSL certificates to all parties. When I set it up, I made no provision for issuing and distributing CRLs (certificate revocation lists), not expecting that to ever be a relevant issue. My server was heartbleed-vulnerable and has now been patched for that; but it appears that as a result of possible past compromise I have to issue new certificates for all the parties and revoke the old ones. My main question is: how do I get the Subversion command-line client to read a CRL? The ssl-authority-files configuration setting lets me specify my CA's root certificate in a file; is there a similar setting for the CRL? I would prefer to distribute the CRL as a file (instead of a URL to be checked automatically); is that possible? Or is it absolutely necessary to post the CRL online somewhere and specify its URL in the root certificate (which will require constructing a new root certificate and a bunch of scripts to periodically re-issue and re-post the file). If it's going to necessitate changes to the root certificate and frequent ongoing maintenance, I might be better off just re-doing the entire public key infrastructure from scratch, annoying as that will be. Note I am specifically asking about the Subversion command-line client running under Linux. I already know how to configure Apache to read the CRL on the server side. All I've been able to find online regarding *client-side* Subversion CRL use is Windows-specific. The answer unfortunately is that currently we don't support CRLs. However, we may have a workaround. We're investigating currently and will follow up with more info soon.
Re: Missing Date and Author in Svn Log ralate to db folder hard link reference count ?
On 3/17/14, 9:12 PM, Steven Wang wrote: My Subversion server install on Centos, running as svnserve. I have follows repositories created on server : I use “svnadmin create” to create repository, some hard link reference count for db folder is 6 (drwxrwsr-x 6 stevenw stevenw 4096 Mar 14 10:00 db) And some is 7. (drwxrwsr-x 7 stevenw stevenw 4096 Nov 22 11:08 db) If hard link reference count is 7 woks ok. But if the count is 6, Date, Author and log message all missing! Could you please help to tell why and how to fix. db is a directory so that field is not the hard link reference count but rather the number of direct children of the directory (an empty directory will always have 2 because of the '.' and '..' entries). Based on what you're saying I'd imagine that you're missing the db/revprops directory in your repository. The only fix would be to recover this data from a backup.
Re: tigris.org down?
On 3/7/14, 2:46 PM, Kyle Sluder wrote: Trying to access the issue tracker, but subversion.tigris.org is dropping connections. It's working for me now.
Re: 502 Bad gateway error
On 3/5/14, 8:01 AM, Guido Larrain wrote: 2014-02-28 8:35 GMT-03:00 Guido Larrain larraingu...@gmail.com mailto:larraingu...@gmail.com: I'm having issues when i tried to commit some HTML files. i mean, some of them i can committed without problems, but others when i tried to commit i'm getting a 502 bad gateway error message. is like is trying to commit for 5 mins and then shows the error message. here is the error that i'm getting Server sent unexpected return value (502 Proxy Error) in response to PUT i did a trace of one of those files that are failing, here is the result... Imágenes integradas 1 I though that it could be an error on the reverse proxy or firewall but those are working fine. Can you please help me on this one? any ideas? The trace you posted is useless in trying to help you because it doesn't demonstrate the issue you've reported as having. The trace shows a 400 error in response to a PROPFIND request and not a 502 error in response to a PUT request. Further the 1.7.9 good trace shows your requests rooted against: http://svn.kaazing.wan/sandbox/trunk While you're 1.8.5 requests rooted against: http://svn.kaazing.wan/ I'm guessing you have your Location in your server rooted at / and are using a ParentPath setup. There's no server at the root so your request with the 1.8.5 client fails. I'm not sure how you managed to produce this request, though it's possible there's some sort of bug here. But there's simply not enough information to determine. The error logs from the server would also be very helpful. Hello, I was trying to find a solution to this and i saw something interesting... Here is another odd behavior… I tried to commit that file as it is… I mean the original Here is the 2 lines with issues centerimg src=some png file here style=margin:auto; width:400px; max-width:100%; / img src=another png file here style=margin:auto; width:400px; max-width:100%; //center So I changed to center img src=another png file here style=margin:auto; width:400px; max-width:100%; / /center As you can see I removed this img src=another png file here style=margin:auto; width:400px; max-width:100%; / and also changed a little bit to be in 3 lines instead of 2 lines. I committed successfully. Then I added that removed line like this… center img src=some png file here style=margin:auto; width:400px; max-width:100%; / img src=another png file here style=margin:auto; width:400px; max-width:100%; / /center I committed successfully and everything is working fine!! Other funny behavior is if you try to commit directly the last step, I'm meaning by replacing this… centerimg src=some png file here style=margin:auto; width:400px; max-width:100%; / img src=another png file here style=margin:auto; width:400px; max-width:100%; //center To this… center img src=some png file here style=margin:auto; width:400px; max-width:100%; / img src=another png file here style=margin:auto; width:400px; max-width:100%; / /center It’ll fail… It doesn't make sense to me, but this is what it is… extremely bizarre!!! Any ideas why this could be happening??? Given this description and the 502 error, I'd guess you have some sort of proxy that doesn't like the content of your PUT. But you haven't provided enough information to really know for sure. You said you initially suspected a problem with the reverse proxy or firewall and assert they are working fine in your last email. What caused you to conclude that they were not at fault? Have you tried the commits without the proxy or firewalls being involved?
Re: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate
On 3/3/14, 2:50 AM, Bert Huijben wrote: -Original Message- From: Daniel Widdis [mailto:wid...@gmail.com] Sent: zaterdag 1 maart 2014 05:06 To: users@subversion.apache.org Subject: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version refused to permanently accept my self-signed certificate, citing an unknown error. Some background on this issue here: http://stackoverflow.com/questions/22108914/subversion-server-ssl-certificate-verification-failed-and-other-reasons We fixed a bug in Subversion where we accidentally accepted certificate issues that were reported after a different first certificate problem. My guess would be that your selfsigned certificate is not completely valid, but we accidentally accepted it before because the first report was just that you weren't a known certificate authority. The second error could then be something like a problem in the certificate chain. Bert's talking about this change from the CHANGES file: * ra_serf: properly ask multiple certificate validation providers for acceptance of certificate failures (r1535532) Which is this change: http://svn.apache.org/r1535532 I was under the impression that this didn't impact our command line client because of the commit message that says we accept all or none of the failures. Looking at the code reinforces that view. It's possible this change is somehow involved, but I'm not seeing how. It could help to upgrade your serf to the latest version as this changes the handling of a few certificate checks. If the internal error is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE (which I happened to reproduce locally some time ago), upgrading to the latest serf should resolve this problem for you. The X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE error issue doesn't make any sense in the context of a self-signed certificate so I really don't think this related. Can you verify which version of serf you're using. You can find this out by running: svn --version -v You'll get a lot of output but you're looking for this: * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.4 - handles 'http' scheme - handles 'https' scheme If you can do this with both the 1.8.5 and 1.8.8 version that would be interesting. I don't use MacPorts myself but it looks like the serf-1 package can be independently upgraded from subversion. We were discussing this on IRC and Lieven suggested that we ask that you generate a new key/cert pair and send them to us so we can try and replicate the behavior. Because as things stand we're not sure what's wrong with the certificate to trigger that other error. Your httpd.conf details would probably be helpful as well.
Re: SVN 1.8.5 svnlook and check_mime_type.pl
On 2/27/14, 12:09 PM, Hartleroad, James [IT] wrote: The check_mime_type.pl isn’t working with SVN1.8 on a unix system. It seems the format of the output of the svnlook proplist command changed so the mime-type is now on a separate line. SVN1.7.4 svn:executable : svn:mime-type : text/x-ksh svn:eol-style : native SVN1.8.5 svn:executable svn:mime-type text/x-ksh svn:eol-style native I couldn’t find an issue open for the check_mime_type.pl script, so I thought I’d check here to see if anyone already had a solution for this. It's in contrib so it's not something we would open an issue on. There is a patch being considered on the dev@ list: https://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C1556940.9RUyJtFJ1Z%40hurry.speechfxinc.com%3E My comments on the patch (doesn't show up from link on that because it crosses the month boundary): https://mail-archives.apache.org/mod_mbox/subversion-dev/201403.mbox/%3C53114EF9.703%40reser.org%3E
Re: problem after update to 1.8.8
On 2/27/14, 2:32 PM, Bill McCormick wrote: $svnlook svnlook: symbol lookup error: svnlook: undefined symbol: svn_pool_create_allocator Any help much appreciated. Looks to me like your svnlook is being dynamically linked against an older version of libsvn_subr. You probably have 1.7.x (or older) libraries somewhere in your environment that are being found and used by the dynamic linker. How did you update? A package, build from source, etc...
Apache Subversion 1.7.16 released
I'm happy to announce the release of Apache Subversion 1.7.16. Please note that Subversion 1.7.16 is the next release after Subversion 1.7.14. The 1.7.15 release was not published publicly, due to issues found during testing. This release addresses one security issues: CVE-2014-0032: mod_dav_svn DoS vulnerability with SVNListParentPath. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: b31c66a06e783c6044b262b71dd8d23c6a5e0b80 subversion-1.7.16.tar.bz2 0ba073960b5a4152bc46f9d8082a508680982d20 subversion-1.7.16.zip a560eca4dfec7afd94ec47f4a5034d33590a6370 subversion-1.7.16.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.16.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.16.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.16.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 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 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 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.16 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.16/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 3:37 PM, Ben Reser wrote: Both mod_authz_default and mod_authz_forbid are registering in the APR_HOOK_LAST group. So their order is not determinate. If you want to avoid mod_authz_forbid activating for any other traffic (with or without mod_authz_default) loaded you should add the following directive inside your server level of your httpd.conf (i.e. outside a Location/Directory block): AuthzForbidAuthoritative On The above should be AuthzForbidAuthoritative Off. Sorry about the typo.
Re: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 11:04 AM, Johannes Michler wrote: well the client is asking over and over again and finally gives up: C:\Users\jmichler\Desktop\testsvn co https://SERVER/svn/PROJEKTE/KUNDE1/trunk/R12/ Authentication realm: https://SERVER:443 PROMATIS Authentifizierung Password for 'user1': Authentication realm: https://SERVER:443 PROMATIS Authentifizierung Username: user1 Password for 'user1': Authentication realm: https://SERVER:443 PROMATIS Authentifizierung Username: user1 Password for 'user1': svn: E215004: No more credentials or we tried too many times. Authentication failed If you're running httpd 2.4.x you probably want this directive in your configuration: AuthzSendForbiddenOnFailure on http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authzsendforbiddenonfailure
Re: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 11:44 AM, Johannes Michler wrote: well I'm using Apache 2.2: apache2 -v Server version: Apache/2.2.22 (Debian) Server built: Jan 31 2014 18:55:37 Is there a workaround for 2.2 as well? Yeah just realized that looking at your original mail. 2.2 shouldn't have that behavior.
Re: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 12:03 PM, Johannes Michler wrote: Well but by looking into my logfiles I see that my server is indeed sending HTTP-401. Is this the problem? I don't think there's really anything that a 1.8 client can or should do different here. The server is saying give me authn credentials and the client is trying to ask for them. The same problem exists for a 1.7 client, it's just that we don't walk up into trees that you're not expecting so you're not seeing this sort of loop (and currently mod_dav_svn returns errors rather than 401's for secondary paths). Looking at the source for mod_authnz_ldap it appears to return a 401 if the group check fails. You've got two basic options here. 1) Patch mod_authnz_ldap so that it returns HTTP_FORBIDDEN. Note that this may cause problems with other configurations that aren't using LDAP this way. 2) Write a custom authz hook that always returns HTTP_FORBIDDEN that hooks after the ldap module. Configure your custom module to be turned on for your location. Then set 'AuthzLDAPAuthoritative off', meaning that the ldap module will DECLINE and the final module should handle this. I'm off to lunch but when I get back I can probably write a quick authz module that does the second bit for you.
Re: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 12:52 PM, Ben Reser wrote:
2) Write a custom authz hook that always returns HTTP_FORBIDDEN that hooks
after the ldap module. Configure your custom module to be turned on for your
location. Then set 'AuthzLDAPAuthoritative off', meaning that the ldap module
will DECLINE and the final module should handle this.
I'm off to lunch but when I get back I can probably write a quick authz module
that does the second bit for you.
First of all I was able to duplicate this with a SVN 1.6.x server, 1.8.x client
and the following setup (without needing LDAP since group file module has the
same behavior):
httpd.conf:
[[[
Location /svn
DAV svn
SVNPath ${HOME}/iprops
AuthType Basic
AuthName Subversion Repository
AuthUserFile ${HOME}/iprops/conf/users
AuthGroupFile ${HOME}/iprops/conf/groups
Require group constant
AuthzSVNAuthoritative off
AuthzSVNAccessFile ${HOME}/iprops/conf/authz
/Location
]]]
users (password is rayjandom for both):
[[[
jrandom:xCGl35kV9oWCY
jconstant:xCGl35kV9oWCY
]]]
groups:
[[[
constant: jconstant
]]]
authz:
[[[
[/random]
jrandom = rw
]]]
I was able to make it work by adding the attached module. It's a slightly
hacked version of mod_authz_default, which comes with httpd 2.2.x (and also
returns a 401). The only differences are I changed the name of the symbols and
configuration settings so that it doesn't conflict with mod_authz_default.
The following should install it (note that on Debian use apxs2 instead of apxs):
apxs -cia mod_authz_forbid.c
Now add the following extra options to the Location block for SVN:
[[[
AuthzDefaultAuthoritative Off
AuthzGroupFileAuthoritative Off
]]]
And now it works with a 1.8 client. The first directive is only needed if
mod_authz_default is built in or loaded as a module. The second line is the
correct option to disable authoritative in the group module. In your case
you'd want to use AuthzLDAPAuthoritative off.
The mod_authz_default module is intended as a fallback in case of there are
Requires lines but no authz hooks is configured as authoritative, which default
behavior in httpd would be to allow that access. So it is desirable to leave
this module enabled but simply enable it for where you're using the
mod_authz_forbid module I've attached.
Both mod_authz_default and mod_authz_forbid are registering in the
APR_HOOK_LAST group. So their order is not determinate. If you want to avoid
mod_authz_forbid activating for any other traffic (with or without
mod_authz_default) loaded you should add the following directive inside your
server level of your httpd.conf (i.e. outside a Location/Directory block):
AuthzForbidAuthoritative On
/* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the License); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#include apr_strings.h
#include ap_config.h
#include httpd.h
#include http_config.h
#include http_core.h
#include http_log.h
#include http_protocol.h
#include http_request.h
typedef struct {
int authoritative;
} authz_forbid_config_rec;
static void *create_authz_forbid_dir_config(apr_pool_t *p, char *d)
{
authz_forbid_config_rec *conf = apr_palloc(p, sizeof(*conf));
conf-authoritative = 1; /* keep the fortress secure by default */
return conf;
}
static const command_rec authz_forbid_cmds[] =
{
AP_INIT_FLAG(AuthzForbidAuthoritative, ap_set_flag_slot,
(void *)APR_OFFSETOF(authz_forbid_config_rec, authoritative),
OR_AUTHCFG,
Set to 'Off' to allow access control to be passed along to
lower modules. (default is On.)),
{NULL}
};
module AP_MODULE_DECLARE_DATA authz_forbid_module;
static int check_user_access(request_rec *r)
{
authz_forbid_config_rec *conf = ap_get_module_config(r-per_dir_config,
authz_forbid_module);
int m = r-method_number;
int method_restricted = 0;
register int x;
const apr_array_header_t *reqs_arr = ap_requires(r);
require_line *reqs;
/* BUG FIX: tadc, 11-Nov-1995. If there is no requires directive,
* then any user will do.
*/
if (!reqs_arr) {
return OK;
}
reqs = (require_line *)reqs_arr-elts;
for (x = 0; x reqs_arr-nelts; x++) {
if (!(reqs[x].method_mask
Re: AW: Unable to access our SVN server using SVN 1.8 client
On 2/25/14, 1:25 PM, Markus Schaber wrote: I tend to think it might be a sensible behavior to not prompt for Authentication on the client side during specifically this kind of upwards tree walk when the client successfully authenticated for the main request, and later fails with the same credentials for a parent directory - it could catch this situation, and just treat it like a forbidden internally. However, I'm not sure whether this is easy to implement given the asynchronous, parallel architecture of serf... If only it were so simple. HTTP is stateless. Just because the credentials worked for some of the requests doesn't mean they will continue working for all requests. Authentication credentials can change. If you just think about passwords that seems absurd but you can't just think about passwords in this case. Digest authentication has the ability to expire nonces. The server gets to decide if the client should be prompted to provide authentication again or not with the stale=TRUE flag. Kerberos has tickets that can expire. Even with basic auth a user can change their password in the middle of an operation. If you think that's silly consider a enterprise system with a checkout that takes a long time to run and a user decides to change their password in the middle (probably a bad idea but we really shouldn't fail). That said this whole thing does raise the issue that a 1.8.x client talking to a 1.7.x or older server that's configured with mixed anonymous/authenticated access is going to prompt users for a password when doing the PROPFINDs for inherited properties unless the anonymous user has access all the way up to the root. When the user happens to have credentials you can consider this beneficial. When the user is a fully anonymous user then this turns into a hassle that means anonymous users have to know to enter a bogus password to trigger the code to stop the inherited properties walk. Granted setups like this are already problematic in other ways, so this isn't entirely new. I'd imagine that's why we haven't already had someone complaining about this. In my opinion Subversion needs the 401/403 distinction to really work properly. There are too many intertwined protocols/implementation details to avoid that now. Add one more detail to why using a stateless protocol is annoying.
Apache Subversion 1.8.8 released
I'm happy to announce the release of Apache Subversion 1.8.8. Please note that Subversion 1.8.8 is the next release after Subversion 1.8.5. The 1.8.6 and 1.8.7 releases were not published publicly, due to issues found during testing. This release addresses one security issues: CVE-2014-0032: mod_dav_svn DoS vulnerability with SVNListParentPath. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: 8e9f10b7a9704c90e17cfe76fd56e3fe74c01a7a subversion-1.8.8.tar.bz2 37790421139d8ce6643a5e690f2cb718ee818cea subversion-1.8.8.zip 0317474e42ba9fdd122030e40b862617ae97a5d0 subversion-1.8.8.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.8.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.8.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.8.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint: 8769 28CD 4954 EA74 87B6 B96C 29B8 92D0 C862 8501 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 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 Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.8 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.8/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Malformed URL
On 2/16/14, 10:21 AM, Florent THOMAS wrote: Hy folks, I'm running a strange issue. I'm trying to make a checkout from a svn 1.8.5 client to a 1.7 repository and I have the following error : svn: E175002: svn: E175002: E125002: Malformed URL '/repo-manager/svn/myrepo/trunk' I'm hosting my repo behind an apache https proxy. It has been working for many months. Something went wrong but I can't identify from wher it come from. What I've done and checked : - On the server machine, I've verified all the revisions = ok - through a webbrowser, I can connect either in https or directly to the repo in a local network - On the server machine, I tried to make a co on file:///path_to_my_local_repo = it works - From a local machine I tried to checkout = Error : svn: E175002: svn: E175002: E125002: Malformed URL '/repo-manager/svn/myrepo/trunk' - I tried with kdesn/tortoisesvn etc Same error - I tried with NetBeans and its embedded javaclient allowed me to checkout without any problem. Where shoudl I check now? What shows in the error logs for the proxy and or the real Subversion server? Does the same thing happen without the proxy. Can you capture the request and response from the server (Wireshark, web debugging proxies like Charles or Fiddler).
Re: Redirect Triggered Relocate for Non-Root Checkout
On 2/7/14, 8:27 AM, Shane Anderson wrote: So, I ask: Why can't the svn update figure this out? The redirect has the root URL in it, with '/trunk' added, and knows the working copies old root URL, so couldn't it just remove the '/trunk' from the redirected/new URL and still do the relocate (just as if it had done the command above?) Already slated to be in 1.8.6: * fix automatic relocate for wcs not at repository root (r1541638 et al)
Re: Multiple SVN repos with single server?
On 2/7/14, 11:57 AM, Tom Malia wrote: Is it possible to server multiple SVN repositories…. Where I mean completely different SVN directories… not separate folders within a single SVN repo… using SVNSERVE on a single server? If so, how? svnserve -d -r /var/svn Where each folder in /var/svn is a separate repository. Then you access each repo with: svn://svn.example.com/reponame where reponame is the name of the folder for the repo in /var/svn. For that matter you could do something (very silly) like -r / and then everyone would have to know the path on your server to reach the repo e.g. svn://svn.example.com/var/svn You can create nested structures this way as well. However, on important bit to remember is for authz svnserve uses the full path under the root for the reponame (including the slash) whereas mod_dav_svn uses only the directory the repo is in. That's because mod_dav_svn doesn't support arbitrary structures like svnserve does.
Re: Multiple SVN repos with single server?
On 2/7/14, 1:28 PM, Bob Archer wrote: We switched from svn:// to http:// and didn't see any pref difference. Then again, I didn't benchmark it. That said, we don't do any path based authorization and that may be the difference. svnserve will be faster if you're committing a lot of files. DAV splits your commit up into multiple PUTs and then has to wait for the server to say that each PUT has succeeded before continuing. The svnserve protocol once it goes into an edit drive just streams the changes to the server and the server only responds if there's an error or the edit drive is finished. Neither of these protocols can use parallelism with sending commits at current since the filesystem backend can't handle it. But once we resolve this DAV should be able to support this which will help lower this cost since multiple round trips can be made at the same time. DAV with more recent versions of Subversion on the client and server side may be faster than svnserve due to skelta mode on checkout, update, switch and diff. In the past DAV would send a report which included the structure and content of the files. With skelta mode DAV will send the structure (and possibly properties) but leave the content to separate GET requests. The Subversion client can make multiple GET requests at the same time, resulting in parallel downloads. If the server can't saturate your network this may result in faster downloads. Additionally, if you're far away from the server these GET requests can be cached unlike the REPORT requests which really could not be. The svn protocol is still sending file content as a single stream and can't parallelize the downloads nor is there any sort of caching capability. There's more info on skelta mode in the 1.8 release notes: https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default Depending on your network environment your mileage may vary. If you really want to know what's faster then you'll need to try it. If you're very close to the server (thus having low latency) you may not notice much difference at all. As Bob has already said there really is nothing stopping you from running both. However, there is one big reason that nobody has mentioned. If you want to get great performance out of the server and you don't have trivial small repositories you should be configuring the memory cache. httpd and svnserve can share a cache if you use memcache, but I believe you'll have better luck if you just use a per process memory cache that can't be shared between servers. You can find some details on this from the 1.7 release notes: https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning One major piece of advice is if you are running httpd, use a threaded MPM (worker or event) as opposed to the prefork MPM. The threaded MPMs will use fewer processes and thus you'll be able to configure a larger cache and since all threads under the same process can share that cache you'll have higher hit rates.
Re: Showing unmerged revisions within a range
On 2/7/14, 4:28 PM, Kyle Sluder wrote:
% svn mergeinfo --show-revs=eligible -r202859 ${Repository Root}/trunk
r200832
r200833
r200836
r200837
[ ... snip ...]
Notice that -r200832 is much earlier than the r202859 argument which was
passed on the command line.
My wild guess is that r200832 was merged to trunk sometime after
r202859? I don't know. Searching the commit log history turns up no such
results.
Unfortunately the -r option on mergeinfo in 1.7 doesn't do anything.
http://subversion.tigris.org/issues/show_bug.cgi?id=4199
This is fixed in 1.8.0 and newer. I'd suggest installing a build of 1.8.5:
https://subversion.apache.org/packages.html#osx
Also be careful mergeinfo needs a source and a target. You're only providing a
single argument there which will be treated as your source and your current
working copy will be used to determine the target.
What's not clear to me is why you're using the revision range the way you are.
Your goal is to make sure anything that was merged to 4.0.2 was also merged to
4.0.x. So I'd probably do the following:
svn mergeinfo --show-revs=merged $REPO/trunk $REPO/branches/4.0.2
merged-4.0.2.txt
svn mergeinfo --show-revs=merged $REPO/trunk $REPO/branches/4.0.x
merged-4.0.x.txt
diff -u 4.0.2.txt 4.0.x.txt
If you get + lines from the diff output that's changes that were merged to
4.0.x that weren't merged to 4.0.2 (which is likely ok). If you get - lines
then you've got changes merged to 4.0.2 that weren't merged to 4.0.x. That is
likely the things you were looking for. If 4.0.x and 4.0.2 weren't branched
off the same point then you'll have some spurious differences. For instance if
4.0.x has been made off a new revision of trunk than 4.0.2 was then you'll see
changes merged from trunk to 4.0.2 that are included since they were made
before the branch point, in which case you can safely ignore revisions that
exist before the branch point (you see to know how to find the branch point
with --stop-on-copy so I won't repeat that).
This might be a good use for the revision range on the mergeinfo to exclude the
changes merged to from 4.0.x but you appear to be trying to use the branch
point for 4.0.2 which isn't what you'd want. Unless of course 4.0.2 is newer
than 4.0.x but it doesn't sound like that's the case.
Finally, save yourself some trouble and learn the ^/ syntax:
https://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls
Re: Showing unmerged revisions within a range
On 2/7/14, 10:45 PM, Ben Reser wrote: Finally, save yourself some trouble and learn the ^/ syntax: https://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls And it's clearly too late since I linked to the wrong relative URL release note. I meant: https://subversion.apache.org/docs/release-notes/1.6.html#repository-root-relative-urls
Re: The XML response contains invalid XML
On 2/4/14, 10:05 PM, Daren Hawes wrote: I was hoping someone has seen this error before. It randomly happens when we SVN Checkout. We have a Windows 2012 Server with SVN 1.8.5 installed. We use Visual SVN 1.8.4 to manage this Server. The Sub Version data folder is on a NAS and permissions look fine. It all works. The SVN is on http://elvis:8080 (no SSL) I can import a whole 1gig site fine, but when I download it to ANY pc I get the error above at random file locations. Does anyone know how I can fix this? Going to need more info to figure this one out. What's in the error log for httpd on the server? If anything? What's in your configuration? Any chance of using Wireshark or a web debugging proxy like Fiddler or Charles to capture the traffic and then see what the response to the REPORT request is? (Fiddler or Charles you'll need to use the proxy configuration in Tortoise's settings under Network). For that matter, does the command line client fail in the same way? Does it give a more descriptive error perhaps?
Re: Solving problem with space in file names
On 2/3/14, 7:33 AM, t...@bbschk.com wrote: The TortoiseSVN user group is sure this stems from subversion itself, and after reading through this mailing list, it seems this problem may be due to the Apache version on my system, which happen to be Apache 2.2.25, which as I understand it has a problem in the mod_dav module that makes it impossible to succeed with a second commit for files with spaces in the name? Yup your problem seems to be exactly PR 55397. As I described here: http://mail-archives.apache.org/mod_mbox/subversion-users/201311.mbox/%3c527c7ac3.5050...@reser.org%3E I am wondering if there is a simple way to solve this if without having to compile a new mod_dav or trying to find another version of Apache? Since I am running OpenIndiana I am simply using the apache that is supplied, and no other version seem to be easily installed… I tried the OpenCSW version, which is 2.2.22, but I get segmentation faults when using the same setup (SVN over web_dav, authentication using PostgreSQL)… If you don't want to upgrade httpd you can upgrade Subversion on the server to 1.7.x or newer and only use 1.7.x or newer clients (which you seem to already be doing by using 1.8.x versions of TortoiseSVN). If the below problem is indeed due to the problematic web_dav, is there a pre-compiled web_dav with the patch suggested in another thread here? This is getting desperate, since I have thousands of files in SVN, many with spaces in the file names, since before upgrading to OpenIndiana… I suspect there are no patched binaries for OpenIndiana. I'd suggest you contact the OpenIndiana project about this.
Re: expanding custom keywords in dump
On 2/3/14, 4:19 AM, Branko Čibej wrote: The patch isn't needed for 1.8, the feature is now standard in Subversion. http://subversion.apache.org/docs/release-notes/1.8.html#custom-keywords
Re: New svn client format (1.7+) breaks when checkout crosses filesystems
On 2/3/14, 2:26 PM, Marc MERLIN wrote: On my personal system, I got a new svn and as prompted by your repo is too old, upgraded it to the new format (svn 1.7.13). You mean working copy, there is no such message about repositories. We support repositories all the way back to 1.0. And now I'm very hosed. legolas:/var/local/scr# svn update svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted legolas:/var/local/scr# svn cleanup svn: E18: Can't move '/.svn/tmp/svn-1FyLjO' to '/var/local/scr/btrfs-subvolume-backup': Invalid cross-device link Indeed, I use svn across my entire system to keep track of changed files, and this goes across filesystems. Been doing this for years, well until now I guess. / is my root /var/local/scr is 2 levels of filesystems mounted on top svn now keeps everything in /.svn it seems and naively assumes it can rename files across locations It's no longer supported for a working copy to cross file systems. Unfortunately, doesn't look like we documented that fact in our release notes: http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng This has caused some issues on Windows as well where permissions become problematic because the files are not made under the same directory as their destination. So it's possible we might change this in the future. But that does nothing to help you right now. I don't really want to rebuild my entire svn checkout in 7 different ones (one per filesystem), not counting that I'd have to manually fix what svn state that isn't synced on each of my client checkouts. What are my options? 1) revert to svn 1.6 but I don't think I can revert my svn repo state without going back to backups, I'm assuming it's a one way upgrade. Before starting it would be a good idea to take a backup of the files if you have concerns about local modifications. Note what revision you're at in your working copy with svnversion (I'll assume $WC is your $WC root from here on out) svnversion $WC Hopefully that's not a mixed revision range, if it is you may have some issues with the following. If it's locally modified that should be ok. Remove the .svn working copy metadata directory: rm -rf $WC/.svn Run the checkout again with 1.6 client where $REV is the revision you got from svnversion and $URL is the $URL to your repo: svn-1.6 checkout --force -r $REV $URL $WC You'll get a lot of E lines (which is the client saying the file already exists). It'll still have your local modifications. However, we no longer support 1.6, so you probably want to upgrade to 1.7/1.8 at some point or you're going to be stuck in the past. 2) split my repo in 7 pieces, which sucks as explaine above (going to be hours of manual work and checking over multiple systems) and reverting/rolling this out. This (splitting your working copy) is probably your best bet. However, to be honest with you this was never a task to which Subversion was made for. I'm guessing you're already using some sort of wrapper to deal with permissions. So it seems to me you need to extend the wrapper to deal with multiple working copies on each file system and keeping them in sync. More than likely you need to request the latest revision from the server (1.7/1.8: use svn info $URL and pull out the Revision: field; 1.9 will have svn youngest for this purpose). Then run svn up -r $REV on each working copy. 3) other :) I don't see any other choices.
Re: Vendor Branches from Foreign Repositories: svn: E200009: Can't set 'svn:eol-style'
On 1/31/14, 5:49 AM, Uwe Tropp wrote: I'm trying to import a vendor branch from a foreign repository by: d:\foosvn copy http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0 Boost svn starts copying, but aborts with E29: Can't set 'svn:eol-style': --- Copying from foreign repository URL 'http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0': : : A Boost\tools\quickbook\test\html\images svn: E29: Can't set 'svn:eol-style': file 'D:\foo\Boost\tools\quickbook\test\html\images\open_clipart_library_logo.svg ' has binary mime type property Since I have no control over the foreign repository I can't fix this issue and am now stuck and unable to complete the import. I think SVN should either skip the properties for this file and place a warning or mark it as a conflict but continue to import instead of abort. Can anybody add this to the issue tracker? Is there a workaround to solve this? I agree, this isn't very useful as it stands. Fixed on trunk with: http://svn.apache.org/r1563361 Don't think we'll backport this to 1.8 since I ended up adding an API. We probably could though with some effort of switch the foreign copy from using the svn_wc_add_from_disk2() into using the other functions that can do all the same things, just can't do them all at once and ultimately end up using svn_wc_prop_set4() which already has the argument to skip the property canonicalization. You could workaround this locally by modifying subversion/libsvn_wc/adm_ops.c to change the skip_some_checks argument to the svn_wc__canonicalize_props() call in svn_wc_add_from_disk2(). That's at line 1016 in the current 1.8.x branch. However, that will disable those checks for all adds (including those done via svn add, svn merge, and svn patch) which I wouldn't recommend for daily usage. But that sort of patch might get you past this issue temporarily.
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
On 1/31/14, 1:54 PM, Steve Davis wrote: :: Attempted to lock the working file svn lock c:\dev\Testrepo\NewDoc.txt Response: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL svn: E200035: Additional errors: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL What if anything is in the httpd error_log? Can you capture the network traffic between the server and the client and post it (removing Authentication headers) for the LOCK request? I’ve first seen this in a Bitnami 2.3.2.1 install, and to try to make sure it’s not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: Same result. I'm not familiar with Bitnami Redmine, can you tell us what version of httpd you have with it? I have tried a totally standalone collabnet svn server install of 1.8.5 on a separate machine, and the locks on that are working. I then put 1.8.5 onto the server where we’re seeing the problem and once again the same problem occurred. So this seems to be an issue occurring as a result of the configuration setup we have on that server. We do make use of an access file on that server, so my next test was to disable the access file setup and retry. This worked exactly as expected (by using a checkout using the local file system), responding that the file had been locked So, it would seem that this issue is related to the use of the following httpd.conf settings: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.s And/or serving the files over https Doubtful. And the related settings pointing to the relevant access authority file. This is more likely. Can you post your configuration?
Re: expanding custom keywords in dump
On 1/31/14, 8:00 PM, Nico Kadel-Garcia wrote: This is why you don't use keywords if you can avoid it, especially for multi-environment projects. Frankly, you will often have diffs with keywords and svn:eol-style: Don't evey try to pretend that anything with keywords is going to be byte for byte consistent between working environments. And this is *especially* why you don't use custom keywords. They're not porable. On Fri, Jan 31, 2014 at 8:27 AM, Thorsten Schöning This doesn't seem to be a keyword which svn clients expand by default, therefore you would have two building lots. http://svnbook.red-bean.com/en/1.8/svn.advanced.props.special.keywords.html Branko gave a perfectly reasonable answer. Beyond that I honestly don't get the point of these two emails. FreeBSD uses keywords because as an open source project they ship source. Even more importantly they have downstream projects (e.g. Apple uses their find command http://opensource.apple.com/source/shell_cmds/shell_cmds-175/find/main.c ). I can't think of a better way of tracking versioning for them once the source leaves their version control system and potentially goes into another. Yes there are all sorts of annoying bits about this. Custom properties don't really make anything more difficult. Since custom properties are repository dictated configuration. In fact the custom property feature was written by the FreeBSD guys and then passed along upstream to ease this burden. They're not expecting Perforce to ever expand these. They stay literal in the source to show the base from upstream. The fact that Perforce doesn't expand it can be considered a feature. So if you're going to critique their technique, how about making a suggestion of a better technique. It's like a couple guys snickering in their Ferrari as a lorry goes by because he could have gotten there much faster in a Ferrari, even though the driver of the lorry only has the goal to get 10 tons of freight there not go fast.
Re: tag rename fails to delete on svnsync mirror
On 1/30/14, 8:52 AM, Jones, Gretchen wrote: Can anyone explain why a tag “renamed” on the master repository is not replicated identically on a mirror? A new tag is created on the mirror but the old tag is not removed on the mirror. SVN 1.7.4 There isn't really sufficient information to give a definitive answer. I'd guess since you're talking about a master and mirror that you're using a master/slave setup. In order for changes to get from the master to the slave there needs to be an svnsync run. Usually that's done via a commit hook. Are you sure your hooks are working?
Re: encountered error with subversion version 1.8.0
On 1/29/14, 8:21 PM, Austin Mico wrote: I have encountered error with subversion. The conf for apache is LocationMatch ^/repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthLDAPURL AuthUserFile /etc/httpd/conf/svnuser_local Limit GET PROPFIND OPTIONS REPORT PROPPATCH POST MKCOL MERGE PUT COPY DELETE MKACTIVITY CHECKOUT require user svnuser /Limit /LocationMatch I think this is being caused by your LocationMatch. Every request is going to think that the server is rooted at the path you're requesting. LocationMatch can be used but you have to be really careful about it and in your particular case I don't think you need it at all. I also don't understand why you're using a Limit block around the require directive. That block is missing the MOVE, LOCK and UNLOCK methods. Assuming that you don't have SVNAutoversioning on turned on somewhere else you can't really do anything useful with those being open to anonymous users (MOVE without auto-versioning requires a transaction/activity which would require a POST or MKACTIVITY in advance and LOCK/UNLOCK are not allowed for anonymous users). So I suspect you really just want all actions against the repository to require the user. So just removing the Limit blocks and put Require user svnuser directly inside the Location block. Not sure what the AuthLDAPURL is doing in there with not value either. With those three things I suspect that your configuration should look like this: Location /repos/endeca/pipeline DAV svn SVNParentPath /var/repos SVNPathAuthz off AuthBasicProvider file AuthType Basic AuthName SVN Login AuthUserFile /etc/httpd/conf/svnuser_local Require user svnuser /Location I encountered error is httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:20 2014] [notice] child pid 2740 exit signal Aborted (6) httpd: subversion/libsvn_subr/dirent_uri.c:2543: svn_fspath__join: Assertion `svn_fspath__is_canonical(fspath)' failed. [Wed Jan 29 22:43:21 2014] [notice] child pid 2742 exit signal Aborted (6) What were you doing when you got this error? Do you have the error from the client, it should be returning an error as well. Even if the above resolves your problem I'd be interested in the above so that we can improve the error message you're getting in the future. I'd also encourage you to upgrade the server to a newer version than 1.8.0, we've fixed some bugs in the meantime.
Re: Need help getting Dreamweaver CS5 to connect to Apache Subversion
On 1/28/14, 12:30 PM, Ryan Schmidt wrote: On Jan 28, 2014, at 08:09, Heather Bartolotta wrote: Rackspace installed Apache™ Subversion® 1.6.11 on our Redhat Enterprise Linux 6 Dedicated Rackspace server. I wonder why? Subversion 1.6 and earlier are no longer supported, ever since the release of Subversion 1.8. http://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation Because that's the version that's still in RHEL6. RedHat doesn't update package versions except by OS version upgrades. They put out patched versions with security updates.
Re: Encrypted passwd on Debian, SVN-Server
On 1/21/14, 8:37 AM, Anselm Arndt wrote: I am trying to store the passwords encrypted in the passwd. The gnome-keyring package could be used for everyone who is using a svn-client, but I want to store the passwords on the server encrypted. Could you give me a hint or a link were I can find a prober solution. My passwords are stored in the default directory (My_Project/conf/passwd) The operating system on the server is DebianSqueeze. You're going to need to say which server setup you're using to answer this. svnserve and httpd have fairly different authentication setups.
Re: Pre step before SVN Merge
On 1/22/14, 9:49 PM, Masood wrote: Can I write hook scripts at server end to perform the task ? If so, can i get any web link for it ? A merge is just a read operation as far as the server is concerned and we don't have hooks for reads. There actually is one Subversion client that supports client side hooks, TortoiseSVN: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks However, I don't think even they have a hook that is appropriate for what you're trying to do. My suggestion in your case would be to write a tool that users would use that would do the actions you want and then run the merge via either bindings or by driving the commandline client. But even then there would be no way to enforce that the tool is used.
Re: upgrade to subversion 1.8.5 suspected bug
On 1/20/14, 9:04 PM, Austin Mico wrote:
If you have this code below which can be viewed exactly like this on browser
on
version 1.8.4
?php
// Define path to application directory
defined('APPLICATION_PATH')
|| define('APPLICATION_PATH', realpath(dirname(__FILE__) .
'/../application'));
// Define application environment
defined('APPLICATION_ENV')
|| define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ?
getenv('APPLICATION_ENV') : 'production'));
// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
realpath(APPLICATION_PATH . '/../library'),
get_include_path(),
)));
/** Zend_Application */
require_once 'Zend/Application.php';
// Create application, bootstrap, and run
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);
$application-bootstrap()
-run();
Here is the the source code viewed on browser after installing 1.8.5-1.
bootstrap() -run();
This is a side effect of the change to setting the filename entry in the
request record with 1.8.5. See the 2nd yellow box here:
http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap
I'd guess you have some sort of handler or filter that's messing with php files.
So post your full httpd conf and I can probably point you at what you have
configured wrong.
Re: upgrade to subversion 1.8.5 suspected bug
On 1/21/14, 9:43 PM, Austin Mico wrote: AddType text/html .php Ryan is entirely right. This is your problem. Add this to your Location for svn: RemoveType .php Or simply move the AddType inside some block a Directory block probably makes the most sense. Since Directory blocks will never match against SVN served traffic now.
Re: Invalid command 'SVNMasterURI' in configuring svn write-through
On 1/17/14, 8:07 PM, WilliamBai wrote: I encounter the following error when configuring the slave machine of svn write-through, Could you give some suggestions? [root@FiOS-DL120-10 ~]# apachectl start [Fri Jan 17 22:51:19 2014] [warn] module dav_svn_module is already loaded, skipping [Fri Jan 17 22:51:19 2014] [warn] module authz_svn_module is already loaded, skipping Syntax error on line 5 of /etc/httpd/conf/extra/httpd-svn.conf: Invalid command 'SVNMasterURI', perhaps misspelled or defined by a module not included in the server configuration Based on this I suspect that you are loading the SVN modules from a version of Subversion before 1.5.0. Given the warning about the svn modules already having been loaded I'd look through all your configuration files for other LoadModule directives loading different svn modules.
Re: Files added to repository by others don't come down with 'svn update'
On Thu Jan 16 02:08:47 2014, Yuri wrote: I first described my issue in the form of the Issue ticket: http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly closed for unclear reasons. There's nothing unclear about why your ticket was closed. Please read the top yellow box on our issue reporting page: http://subversion.apache.org/reporting-issues.html We don't put issues into the ticket system until we're sure they're actual bugs. We handle figuring out that they're actual bugs here. If a developer confirms your issue usually we'd ask you to file an issue, in this case we'd probably just reopen your issue. The explanation in this ticket says you somehow deleted your current directory. Well, I am positive I did not. In short: I had the checked out subversion directory. Somebody else added few files into the repository, then I deleted the enclosing sub-directory, updated it with 'svn update', and the added by others files failed to appear. And they also failed to appear after overall 'svn update'. What do I do now? I obviously have an invalid directory, and I didn't do anything wrong. I believe this indicates the presence of some problem in subversion. But this Issue has been assertively closed. I started to take a look at your issue but didn't get very far with it because the freebsd-ports tree is rather large and the checkout was taking a long time. So a much more specific recipe would be greatly helpful (hopefully one that doesn't require making a large checkout). So I'd follow the instructions here with respect to providing the reproduction recipe and environmental details: http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs I know that page says to send the email to the dev list but you can reply here since you've already started a thread.
Re: SVN 1.8.x erroneously assumes a reintegrate merge and gives error E195016
On 1/16/14, 8:34 AM, Keath Milligan wrote: We are running into an issue similar to the one described in http://svn.haxx.se/users/archive-2013-12/0171.shtml when performing some sync merges. svn issues error E195016: Reintegrate can only be used if revisions…” but this isn’t a reintegrate merge. When this happens, the only work around appears to be to specify the revision range to merge explicitly, which is very confusing and error prone for less experienced users. Is there something we can do to help svn’s reintegrate logic work better? Note that this is not the dropped character problem described in other posts. We have confirmed that all of the paths in svn:mergeinfo are correct. Can you provide a minimal reproduction recipe (starting with a new repository) that demonstrates the issue? It's very difficult to diagnose merge issues without looking at the repository (which I'm going to assume you can't let us do, though if you could that may be helpful) because the history is very important to the behavior of merge. Some general guidelines on how to report a bug are here: http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
Re: How to recreate rep-cache.db if it wasn't writable for some time ?
On 1/16/14, 6:08 AM, Olivier Berger wrote: (please CC: me as not subscribed) Hi. The bug report rep-cache.db created without group write bit [0] seems to be on the way of being solved (AFAIU, the fix isn't released yet). Correct, no release includes this yet. I don't think it's been nominated either. I'll poke Philip about his intentions here. I cannot seem to find a reference to a repair solution to recreate the contents of the DB cache (svnadmin recover doesn't address it AFAICT). The document at [1] mentions that This file is only consulted during writes and never during reads. Consequently, it is not required, and may be removed at an abritrary time, with the subsequent loss of rep-sharing capabilities for revisions written thereafter. But AFAIU, if the file is removed, it gets recreated anyway, staring from the next commit, unless enable-rep-sharing = false... So I'm wondering : if the file is incomplete, is there a risk ? And if not, how may we recreate the contents of the cache ? Right now there's no way to do this other than a dump/load cycle since the only place the rep cache is written is during a commit. For what it's worth I recall mentioning to Stefan Fuhrmann that we didn't seem to have a way to rebuild the db and I have a hazy memory of him telling me that we did. Looking at the code however, makes me think we don't (and I even looked at trunk). Now as to your comment about risk. There is no risk. If the file is missing or incomplete it won't break anything. The only issue is that if commits are missing then the representations they wrote cannot be used to avoid writing identical new representations. The end result of this is that your repository may be bigger. It seems that the algorithm would be quite simple from reading [1], but that's beyond my capacity investigating SVN internals, I'm afraid. You're right it should be relatively easy to write some code to rebuild it (I suspect figuring out where this functionality should go from a UI perspective will be harder than writing the code). Even if we had functionality to rebuild this db, if you're concerned about this it'd still probably be best to do a dump/load. Simply because if you weren't writing the rep-cache while some revisions were committed, then some of those revisions may contain duplicate representations. So you repository might still be slightly bigger. However, we ought to be able to detect that and tell you that you repo would shrink if you ran a dump/load. In fact that might be a useful feature to admins trying to decide if a dump/load is worth it (time vs space).
Re: Bug ? With SVN 1.8.4 on Mac
On 1/16/14, 12:34 PM, Bert Huijben wrote: That script is only going to help you for the platform invariant error codes in Subversion itself + the codes on the platform you are checking on. It knows about APR's errors as well (not that this is important in this case), see the aprerr.txt file in tools/dev
Re: svn log --xml -g doesn't identify a reverse merge but svn log -g does
On 1/16/14, 12:31 PM, Andrew Reedick wrote: I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something? Problem: svn log -g will explicitly identify a reverse merge, however, when specifying xml output (svn log -g --xml) no such identification is made. Yup looks like an oversight. The nesting already shows that it's a merge and what revision made the merge. But we don't show the direction of the merge. I've coded up a trivial change to add a reverse-merge attribute on the logentry element in this case. e.g. logentry revision=13 reverse-merge=true Once I write a test for it I'll commit it. Given that it changes the XML output, I probably wouldn't backport this to 1.8.x.
Re: svn log --xml -g doesn't identify a reverse merge but svn log -g does
On 1/16/14, 1:38 PM, Ben Reser wrote: On 1/16/14, 12:31 PM, Andrew Reedick wrote: I need a sanity check. Is this an oversight that needs to be corrected, or am I missing something? Problem: svn log -g will explicitly identify a reverse merge, however, when specifying xml output (svn log -g --xml) no such identification is made. Yup looks like an oversight. The nesting already shows that it's a merge and what revision made the merge. But we don't show the direction of the merge. I've coded up a trivial change to add a reverse-merge attribute on the logentry element in this case. e.g. logentry revision=13 reverse-merge=true Once I write a test for it I'll commit it. Given that it changes the XML output, I probably wouldn't backport this to 1.8.x. Opened issue #4463 for this: http://subversion.tigris.org/issues/show_bug.cgi?id=4463
Re: svn log --xml -g doesn't identify a reverse merge but svn log -g does
On 1/16/14, 1:59 PM, Ben Reser wrote: Opened issue #4463 for this: http://subversion.tigris.org/issues/show_bug.cgi?id=4463 Fixed in r1559032. I anticipate that the fix will be included in 1.9.0.
Re: Locking whole directories
On 1/13/14, 7:02 PM, Kyle Sluder wrote: I understand that implementing this would require all commits to search for lock properties on every ancestor of every changed file or directory. It essentially amounts to an extension of inheritable properties to the RA layer. Which would be pretty neat, IMO. :) Well not really. Locks aren't a property so none of the inheritable properties work helps here. Inheritable properties also already have RA support (which is a big reason to prefer a 1.8 server to be used with a 1.8 client since the RA support is much more efficient than walking the tree). DAV already has support for recursive locks (including locks) on directories. So we'd shouldn't need any new protocol changes for DAV. Presumably we can come up with something efficient for svnserve. Shall I file a feature request? Surprised we don't already have a feature request for directory locks already. So please do so. Understand that filing an issue doesn't mean it's going to be immediately worked on.
Re: Locking whole directories
On 1/15/14, 9:52 AM, Branko Čibej wrote: There's probably a good reason why we didn't implement directory locks when the locking feature was developed. In any case it's not a trivial feature. I don't recall what the reason was at the time, but I'd bet it was just a pain to deal with the inheritance and since most people were satisfied with file locks, everyone just stopped there.
Re: Locking whole directories
On 1/15/14, 10:22 AM, Kyle Sluder wrote: To be clear, this isn't implying that `svn lock` of a directory will work over DAV, correct? Just that the repository supports storing the fact that some other DAV client has LOCKed a directory, and the DAV protocol layer supports communicating that information back to the `svn` client? Not even that much is done. I meant that the DAV RFC includes details on how locks on collections (DAV's name for directories) should work. DAV handles the inheritance by supporting a depth parameter for the lock. Basic model for how looking should work that specifies some behavior related to depth-infinity locks: http://webdav.org/specs/rfc4918.html#lock-model Specific section on directory locks. http://webdav.org/specs/rfc4918.html#write.locks.and.collections One problem that may arise here is we may not like how DAV implemented directory locks. If not then we have the issue of our LOCK method support not really being compatible with DAV.
Re: Locking whole directories
On 1/15/14, 10:34 AM, Branko Čibej wrote: We certainly have to hack thinks to map non-recursive directory locks to any reasonable locking model in Subversion. This is because of Subversion's bubble-up storage model, in which the revisions of all parent directories of a change are updated by a commit. I don't really see that as a problem at all. Locks are enforced at the RA layer. For instance in mod_dav's case the locks are actually enforced by mod_dav itself with it asking mod_dav_svn if there are any applicable locks. So the bubble up wouldn't even impact the current implementation if we extended it for directories. If we wanted to move the enforcement into the filesystems at some point, I guess that would become a complication, but until/unless we get rid of using mod_dav I think that's not going to be palatable. Inheritance is also an interesting topic, and the fact that Subversion allows locks to be created on nonexistent paths (and that our locks don't record the recursive vs. non-recursive bit) would also make for interesting side effects. Non-existent paths for directories are less of an issue that you might think. The need for locking non-existent files (in generic DAV) is because PUT overwrites a file's content even if it already exists. So two users PUT'ing to the same location will end up having a race with only the last users content being preserved. The old DAV spec implemented this by using the whole lock null stuff where you don't actually create the file but the server keeps track that a lock null resource exists (clients can then pretend like the file exists or not depending on their preferences). Collections don't have this issue because you can't use MKCOL to overwrite an existing collection. You'd have to explicitly remove the existing directory. So in the case of two users both trying to create a collection, they'd race and the second one would fail due to the already existing collection. DAV when it was updated in 2007 deprecated this whole lock null nonsense and replaced it: http://webdav.org/specs/rfc4918.html#lock-null http://webdav.org/specs/rfc4918.html#lock-unmapped-urls As I read the spec, it seems to me that it is required that all LOCKS on non-existent (unmapped in DAV terminology) URLS are treated as file locks, and that creating a lock on a non-existing collection is not allowed. Since you don't NEED the lock on a non-existent directory due to the behavior of MKCOL I believe this makes sense. Additionally, we only allow locks on non-existent paths with auto-versioning, so our support here is to entirely work around the above. There's not even a UI confusion with a svn client since we disallow this behavior from them. One complication if we switch to the new LOCK model for DAV (LOCK actually creates empty files) is that a LOCK on an non-existent file would become a commit and a lock. I suspect we don't want to mess with that since the lock null resource implementation works fine and I don't think there's any need to switch in order to support directory locks, the model doesn't appear to be altered from the RFC 2518 spec. We'd need a format bump to add a depth field, but that doesn't seem to be a huge deal. It'd just be yet another repository controlled capability. Since all existing locks are file locks it's trivial to add the depth field (for that matter it's irrelevant what the depth field is because the behavior for all the values of depth for a file is the same). The biggest effort with respect to the storage is making it efficient to search for inherited locks. Right now create an index for locks but it can be flaky, in order for inherited locks to work well it'd have to be rock solid.
Re: Locking whole directories
On 1/15/14, 12:44 PM, Kyle Sluder wrote: Is there foreseeable benefit to moving them into the FS layer? I can't think of any benefit other than a design that seems cleaner. I'm sure Branko can though. To be completely explicit, the problem as I understand it is that since touching a file in the FS layer touches all its ancestors, implementing non-recursive locks in the FS layer would be problematic because touching an unlocked file might require touching a locked ancestor. That's a theoretical problem of a theoretical fs implementation that doesn't exist (and probably can't exist without Subversion 2.0). Branko's thinking about that because he's been thinking about completely new FS implementations. How specifically does implementing locks in the RA layer sidestep the issue? Is it because the bubble-up semantics are confined to the FS layer, or is it because the RA layer can choose to bend the rules and say yes, committing changes to /a/b/c bumps the revision of non-recursively-locked ancestor /a, but since there are no real modifications to that directory, I will allow this change? Does this have any implications for higher levels of the stack—for example, would a DAV client be confused that a supposedly-locked collection has changed? The fact that the bubble up happens is an implementation detail of the FS layer. For instance, Branko actually has thought about a design without the bubble up. The RA layer doesn't really know about that bubble up. It just knows that you're touching /a/b/c, so it checks the lock state on that node (and if we add recursive locks applying whatever sort of inheritance rules apply to the locks that exist). I.E. it's checking the actual operations that you're executing against the locks, not the side effects on the DAG. DAV clients support a 0 depth (non-recursive) and an infinity depth. 0 depth means only the collection itself is locked. Though that does include changing the children of the collection since that's a property of the collection. So a 0 depth lock would not allow you to add or remove files from the collection, but you could change the contents of files already present. Infinity depth is fairly obvious, all children of the collection and their children and so on are locked. If this is what we add support for I don't see any issues for DAV clients. Clients can't presume that their locks can't be removed except by them since the DAV spec says that servers may allow privileged users other than the lock creator to remove locks: http://webdav.org/specs/rfc4918.html#lock-creator I suspect DAV clients in general don't ever try to use locks on directories anyway since they we haven't ever had someone come along complaining that their DAV client doesn't work with auto-versioning due to our lack of directory locks (though I'll admit actual use of auto-versioning is pretty limited). So I'm having a hard time envisioning a scenario with adding support for directory locks (non-recursive or recursive) breaks them.
Re: difference between svn copy -r REV SRC and SRC@REV
On 1/15/14, 1:05 PM, Mojca Miklavec wrote: I was wondering whether -r REV SRC and SRC@REV in svn copy are supposed to behave differently or not. Yes they have different behavior. You probably want to read about Peg and Operative Revisions here: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
Re: Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
On 1/9/14, 11:19 AM, Branko Čibej wrote: To be clear, I'm not saying that any of these things are configured incorrectly; only that they may be interacting with Subversion in a way that we don't handle well. One of the major differences between 1.7 (which works) and 1.8 (which fails) is that we try to work around issues with non-standard behaviour of certain transparent (sic) proxies; and we can't claim to have covered all the possibilities. Actually we know we haven't covered all possibilities. Had someone a while back that had mod_security setup in such a way that it was rejecting some request methods (think it was POST) without Content-Length (thus breaking chunked requests). The behavior didn't fail for the OPTION requests so our probe to try and work around transparent proxies failed. But I'm not sure what this thread would really have to do with chunked requests, since the problem seems to be pipelining which as far as I know we don't have any workarounds for. We can rule out the chunked requests by disabling it by adding this to the command line --config-option servers:global:http-chunked-requests=no and seeing if it changes anything. But I really doubt it based on what I've seen on this thread. More details on what Branko is talking about and the config option I mentioned here: https://subversion.apache.org/docs/release-notes/1.8.html#411-length-required
