Re: svn commit: r1908545 - /subversion/trunk/build.conf
Those functions are not exported from the dll on Windows, -only specific marked functions are, ulike unix where we export everything- so a workaround was needed to access those functions from our test suite. This patch will break testing on Windows, but with +- all the buildings down for different forms of maintenance nobody notices. The old issue was test only, and I don't think just breaking all WC test on Windows just for build sanityvreasond is a proper fix. This will need a proper fix to allow release testing on Windows again. Bert Sent from Outlook for Android<https://aka.ms/AAb9ysg> From: Nathan Hartman Sent: Sunday, May 28, 2023 4:12:25 PM To: Daniel Sahlberg Cc: Jun Omae ; phi...@apache.org ; dev@subversion.apache.org Subject: Re: svn commit: r1908545 - /subversion/trunk/build.conf On Sun, May 28, 2023 at 5:11 AM Daniel Sahlberg wrote: > > Good catch Jun! > > Den sön 28 maj 2023 kl 07:33 skrev Jun Omae : >> >> Hi, >> >> On 2023/03/20 10:20, phi...@apache.org wrote: > > [...] >> >> > == >> > --- subversion/trunk/build.conf (original) >> > +++ subversion/trunk/build.conf Mon Mar 20 01:20:29 2023 >> > @@ -1337,7 +1337,7 @@ msvc-force-static = yes >> > description = Test Sqlite query evaluation >> > type = exe >> > path = subversion/tests/libsvn_wc >> > -sources = wc-queries-test.c ../../libsvn_subr/sqlite3wrapper.c >> > +sources = wc-queries-test.c >> > install = test >> > libs = libsvn_test libsvn_wc libsvn_subr apriconv apr sqlite > > > This reverts the first half of half of r1536364: > > [[[ > Don't compile the SQLite amalgamation twice. The WC test can use the same > wrapper as libsvn_subr. > > * build.conf (wc-queries-test): Add sqlite3wrapper from libsvn_subr to > sources. > * subversion/tests/libsvn_wc/wc-queries-test.c: Don't include sqlite3.c; >Instead, use the same method as libsvn_subr/sqlite.c to import the >wrapped functions from sqlite3wrapper.c > (test_sqlite_version): Call sqlite3_libversion instead of using the >sqlite3_version array directly, since the latter is not exported from >sqlite3wrapper.c. > ]]] > > The code in wc-queries-test.c and sqlite.c seems to be exactly the same. > > @philip: What was the exact error message from the gcc sanitizer and can you > dig a little deeper to see if it could be resolved in another way? > > Kind regards, > Daniel Sahlberg svn_sqlite3__api_initialize, svn_sqlite3__api_funcs, etc., not being exported under Windows build? Or are exported with mangled names for some reason? (e.g., could happen if built as C++ (e.g., MSVC /TP switch) and extern declarations aren't wrapped with 'extern "C"'.) I feel like building/linking twice was a kludge that could happen because of something like that. Nathan
RE: svn commit: r1905663 - in /subversion/branches/pristines-on-demand-on-mwf/subversion: include/ include/private/ libsvn_client/ libsvn_wc/
All the now deprecated functions now fail unconditionally when the setting is enabled. Isn’t it possible to do this more graceful whenever a file is encountered which misses it’s prisite version? � As far as I know it is expected that some of the files do have pristines, while others don’t… That would allow things like diffs on old clients that didn’t switch apis yet. � � And in many cases these clients might just pass a wc-ctx that was created with the client api, so they might even have support for obtaining the pristines via callbacks without even knowing… but now they fail because we just check a single boolean in the deprecated api. � � I’m not even sure if this is really worth revving the apis without altering the arguments… We introduced new error codes on existing apis before, like when we switched to WC-NG. � Bert � From: Daniel Sahlberg Sent: Thursday, December 1, 2022 1:14 PM To: dev@subversion.apache.org Cc: comm...@subversion.apache.org Subject: Re: svn commit: r1905663 - in /subversion/branches/pristines-on-demand-on-mwf/subversion: include/ include/private/ libsvn_client/ libsvn_wc/ � Den tors 1 dec. 2022 kl 11:42 skrev mailto:kot...@apache.org> >: Author: kotkov Date: Thu Dec � 1 10:42:41 2022 New Revision: 1905663 � [...] � � Modified: subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h URL: http://svn.apache.org/viewvc/subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h?rev=1905663 <http://svn.apache.org/viewvc/subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h?rev=1905663=1905662=1905663=diff> =1905662=1905663=diff == --- subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h (original) +++ subversion/branches/pristines-on-demand-on-mwf/subversion/include/svn_error_codes.h Thu Dec � 1 10:42:41 2022 @@ -581,6 +581,12 @@ SVN_ERROR_START � � � � � � � SVN_ERR_WC_CATEGORY_START + 42, � � � � � � � "Incompatible working copy settings") + � /** @since New in 1.15 */ + � SVN_ERRDEF(SVN_ERR_WC_DEPRECATED_API_STORE_PRISTINE, + � � � � � � �SVN_ERR_WC_CATEGORY_START + 43, + � � � � � � �"This client was not updated to support working copies " + � � � � � � �"without local pristines") + � �/* fs errors */ � Is it really "This client"? It looks more to be based on the WC setting. � Kind regards, /Daniel �
RE: SlikSVN/SharpSvn link on website
Thanks! � I moved most of the projects I worked on, from open.collab.net to below https://github.com/ampscm/ (Help / pull requests welcome! ;-) � Bert � From: Daniel Sahlberg Sent: Tuesday, November 29, 2022 10:30 PM To: Mark Phippard Cc: Subversion Development ; rhuij...@apache.org Subject: Re: SlikSVN/SharpSvn link on website � Den tis 22 nov. 2022 kl 14:33 skrev Mark Phippard < <mailto:markp...@gmail.com> markp...@gmail.com>: On Mon, Nov 21, 2022 at 5:47 AM Daniel Sahlberg < <mailto:daniel.l.sahlb...@gmail.com> daniel.l.sahlb...@gmail.com> wrote: > > Hi, > > On the Binary Packages page [1], under Windows, there is a link to SlikSVN: > "...maintained by Bert Huijben, SharpSvn project". > > The name and project links to <http://open.collab.net> open.collab.net, > which currently doesn't work (outdated SSL protocol version). > > Shall we replace this text with another link? I found a github page [2] which > seems to be the successor. I'd suggest you just make the change and let Bert followup if he chooses. There is no value in maintaining the current links that have not been valid for years. � Thanks. I allowed it to soak for one more week but committed �r1905623 tonight. � /Daniel �
Re: svn commit: r1903814 - /subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c
File externals didn't exist in the entry world, so you can ignore that edge case. Older code will just detect them as a switched path which is fine, as that is essentially what they are anyway. Normal (directory) externals should be mapped, but I assume they already are or we would have found these earlier on in the WC-NG migration. The lock flag is seldom tested, nor seen from testcode as it would imply the working copy is broken by some operation If we have such a testcase, we usually fix the real issue instead of increasing test coverage. (The issue was far more common pre WC-NG, where we didn't have true recursive operations... so we had to lock on many levels separately) Bert On Fri, Sep 9, 2022 at 10:46 PM Nathan Hartman wrote: > On Fri, Sep 9, 2022 at 6:31 AM Bert Huijben wrote: > > > > Why the branch? > > Looks like a quite obvious fix to me, so you could have just committed > this to trunk. > > That does seem a little excessive, doesn't it? :-) > > I'll merge and nominate for backport when I get to a computer. > > I wanted to write a regression test too, but got stuck there -- was > looking for the right place to add it and something that already > exercises that version API to use as a starting point. > > The test suite (without a new regression test) didn't throw up any > complaints. > > Btw, while looking at this, I found we also aren't copying the > 'external' flag (or file_external, I don't have the name handy at the > moment), so I'll fix that too. > > AFAICT we're copying/translating everything else that has a > representation in the older struct. So, just the lock and external > flags are missing. > > > +1 on backporting this fix, although I would recommend users of the old > (pre 1.7) api to upgrade to the newer status apis, as that makes an insane > amount of performance difference on most platforms. > > Cool. I'll add your vote when I nominate it... > > Cheers, > Nathan >
Re: svn commit: r1903814 - /subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c
Why the branch? Looks like a quite obvious fix to me, so you could have just committed this to trunk. +1 on backporting this fix, although I would recommend users of the old (pre 1.7) api to upgrade to the newer status apis, as that makes an insane amount of performance difference on most platforms. Bert On Thu, Sep 1, 2022 at 4:10 PM wrote: > Author: hartmannathan > Date: Thu Sep 1 14:10:23 2022 > New Revision: 1903814 > > URL: http://svn.apache.org/viewvc?rev=1903814=rev > Log: > On the 'issue-4908' branch, add the proposed fix > > * subversion/libsvn_wc/deprecated.c > (svn_wc__status2_from_3): To allow users of deprecated APIs, such as > PySVN, >to detect working copy locked status, copy 'locked' from old_status to >status. > > Modified: > subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c > > Modified: subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c > URL: > http://svn.apache.org/viewvc/subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c?rev=1903814=1903813=1903814=diff > > == > --- subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c > (original) > +++ subversion/branches/issue-4908/subversion/libsvn_wc/deprecated.c Thu > Sep 1 14:10:23 2022 > @@ -2815,6 +2815,7 @@ svn_wc__status2_from_3(svn_wc_status2_t > } > >(*status)->entry = entry; > + (*status)->locked = old_status->locked; >(*status)->copied = old_status->copied; >(*status)->repos_lock = svn_lock_dup(old_status->repos_lock, > result_pool); > > > >
RE: svn commit: r1902364 - /subversion/trunk/build.conf
That line will add the ./configure time dependencies (or gen-make.py for Windows). The dependencies on our own libraries are added by the ‘libs =’ line right above. � If you don’t get these, then it is most likely because the files don’t exist/aren’t build at the right time, and in that case you need to use a different make target, like you already suggested. � � Adding more and more unneeded dependencies will make things far harder to diagnose in the future, so we should remove strange inner dependencies for just a specific environment, or use the proper systems if we ever want to be able to find bugs in this space. � Bert � From: Daniel Sahlberg Sent: Monday, July 4, 2022 4:29 PM To: Subversion Development Cc: comm...@subversion.apache.org Subject: Re: svn commit: r1902364 - /subversion/trunk/build.conf � Den mån 4 juli 2022 kl 16:07 skrev Bert Huijben mailto:b...@qqmail.nl> >: > == > --- subversion/trunk/build.conf (original) > +++ subversion/trunk/build.conf Thu Jun 30 08:10:48 2022 > @@ -340,6 +340,7 @@ type = ra-module > � path = subversion/libsvn_ra_serf > � install = serf-lib > � libs = libsvn_delta libsvn_subr aprutil apriconv apr serf zlib > +add-install-deps = $(SVN_FS_LIB_INSTALL_DEPS) > � msvc-static = yes > � > � # Accessing repositories via SVN Why add this dependency to libsvn_ra_serf? I think you have a different problem in your build if you need the fs libraries for building the serf ra layer. � Probably :-). I think I need some pointers where to look to understand the build system. � The problem (the longer version has been discussed here already here and is documented in issue #4901) is that �make install-serf-lib fail when linking �libtool: warning: relinking 'libsvn_ra_serf-1.la <http://libsvn_ra_serf-1.la> ': /usr/bin/ld: cannot find -lsvn_delta-1 /usr/bin/ld: cannot find -lsvn_subr-1 � As far as I could determine these were installed by �make install-fsmod-lib. But again, I'm new to this... � Kind regards, Daniel �
RE: svn commit: r1902364 - /subversion/trunk/build.conf
Most likely this user just has a bunch of libraries in that environment variable, and this links the ra layers to quite a few dependencies it doesn't need, potentially loading things like BDB in cases where it Is absolutely not necessary. There are other better ways to add the depencies to specific libraries, like that libs line right above this. This line links the fake serf target, which does have the dependencies for serf... And that one would need fixing if the user has a problem. -Original Message- From: Bert Huijben Sent: Monday, July 4, 2022 4:07 PM To: dev@subversion.apache.org; comm...@subversion.apache.org Subject: RE: svn commit: r1902364 - /subversion/trunk/build.conf > == > --- subversion/trunk/build.conf (original) > +++ subversion/trunk/build.conf Thu Jun 30 08:10:48 2022 > @@ -340,6 +340,7 @@ type = ra-module > path = subversion/libsvn_ra_serf > install = serf-lib > libs = libsvn_delta libsvn_subr aprutil apriconv apr serf zlib > +add-install-deps = $(SVN_FS_LIB_INSTALL_DEPS) > msvc-static = yes > > # Accessing repositories via SVN Why add this dependency to libsvn_ra_serf? I think you have a different problem in your build if you need the fs libraries for building the serf ra layer. Bert
RE: svn commit: r1902364 - /subversion/trunk/build.conf
> == > --- subversion/trunk/build.conf (original) > +++ subversion/trunk/build.conf Thu Jun 30 08:10:48 2022 > @@ -340,6 +340,7 @@ type = ra-module > path = subversion/libsvn_ra_serf > install = serf-lib > libs = libsvn_delta libsvn_subr aprutil apriconv apr serf zlib > +add-install-deps = $(SVN_FS_LIB_INSTALL_DEPS) > msvc-static = yes > > # Accessing repositories via SVN Why add this dependency to libsvn_ra_serf? I think you have a different problem in your build if you need the fs libraries for building the serf ra layer. Bert
RE: Buildbot Migration
Hi Gavin, Thanks. The buildbots report that they are attached now: [[ 2022-04-22 09:43:03+0200 [-] recording hostname in twistd.hostname 2022-04-22 09:43:03+0200 [-] Starting factory 2022-04-22 09:43:03+0200 [Broker,client] message from master: attached 2022-04-22 09:43:03+0200 [Broker,client] I have a leftover directory 'svn-local' that is not being used by the buildmaster: you can delete it now 2022-04-22 09:43:03+0200 [Broker,client] I have a leftover directory 'svn-test-run' that is not being used by the buildmaster: you can delete it now 2022-04-22 09:43:03+0200 [Broker,client] Connected to buildmaster; worker is ready 2022-04-22 09:43:03+0200 [Broker,client] sending application-level keepalives every 600 seconds ]] Looks like the next step would be to re-enable the builds in the Subversion config. Nathan do you want to look at that? Or anybody else? (I see that the Subversion config is renamed to .disabled and I assume quite a few builds don't apply any more) Otherwise I will look into this, next weekend. Thanks, Bert! -Original Message- From: Gavin McDonald Sent: Thursday, April 21, 2022 10:18 PM To: dev@subversion.apache.org Subject: RE: Buildbot Migration Hi Bert, I emailed you some new connection details a few hours ago, let me know if your workers can connect and I'll see about enabling those jobs. I have also changed the config for the ubuntu jobs to use asf hardware. That leaves the mac builds - if nobody can source a mac I'll see what I can do my end Gav... On 2022/04/14 11:08:40 Bert Huijben wrote: > I upgraded the win32 buildbots to python 3.10 and new buildbot and they now > try to connect to buildbot using the old credentials, but fail as the server > doesn't expect the bot to connect. > > Can somebody try to obtain new credentials for or re-enable the old > credentials, so I can continue getting this SlikSvn sponsored bot back up. > > > > Thanks, > Bert > > -Original Message- > From: Nathan Hartman > Sent: Sunday, April 10, 2022 5:33 PM > To: Subversion Developers > Subject: Re: Buildbot Migration > > On Tue, Jan 18, 2022 at 10:52 AM Nathan Hartman > wrote: > > > > On Tue, Jan 18, 2022 at 10:45 AM Nathan Hartman > > wrote: > > > > > > On Sun, Jan 16, 2022 at 3:56 PM Branko Čibej wrote: > > > > > > > > On 16.01.2022 18:33, Nathan Hartman wrote: > > > (snip) > > > > > Are "svn-w2k3-local" and "svn-x64-macosx-dgvrs" currently the > > > > > only nonexistent nodes referenced by this script? > > > > > > > > Existent but not upgraded, at least in the case of the mac mini. > > > > > > > > Someday ... > > > > > > All the more reason to activate whatever is ready now and add > > > others back if/when they are ready. I'll go ahead and request to do > > > that... > > > > That's filed under INFRA-22761... > > > As part of the recent migration from buildbot 0.8 to 3.2 and ci.a.o to > ci2.a.o, we have had no buildbots since late last year. > > I think most of our buildbot configs should be able to run on 3.2, except for > svn-w2k3-local and svn-x64-macosx-dgvrs, so as a stopgap measure, I tried > commenting the aforementioned two and activating the config by renaming [3] > to remove the "-disabled" suffix. > > However, Gavin McDonald comments on INFRA-22761: "I'm afraid we still can not > activate this config. There are no agents in which any of the builders can > use at this point." > > Any ideas what we should do to get some buildbots back online? > > [1] https://issues.apache.org/jira/browse/INFRA-22277 > > [2] https://issues.apache.org/jira/browse/INFRA-22761 > > [3] > https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/s > ubversion.py > > Cheers, > Nathan > >
RE: Buildbot Migration
I upgraded the win32 buildbots to python 3.10 and new buildbot and they now try to connect to buildbot using the old credentials, but fail as the server doesn't expect the bot to connect. Can somebody try to obtain new credentials for or re-enable the old credentials, so I can continue getting this SlikSvn sponsored bot back up. Thanks, Bert -Original Message- From: Nathan Hartman Sent: Sunday, April 10, 2022 5:33 PM To: Subversion Developers Subject: Re: Buildbot Migration On Tue, Jan 18, 2022 at 10:52 AM Nathan Hartman wrote: > > On Tue, Jan 18, 2022 at 10:45 AM Nathan Hartman > wrote: > > > > On Sun, Jan 16, 2022 at 3:56 PM Branko Čibej wrote: > > > > > > On 16.01.2022 18:33, Nathan Hartman wrote: > > (snip) > > > > Are "svn-w2k3-local" and "svn-x64-macosx-dgvrs" currently the > > > > only nonexistent nodes referenced by this script? > > > > > > Existent but not upgraded, at least in the case of the mac mini. > > > > > > Someday ... > > > > All the more reason to activate whatever is ready now and add others > > back if/when they are ready. I'll go ahead and request to do that... > > That's filed under INFRA-22761... As part of the recent migration from buildbot 0.8 to 3.2 and ci.a.o to ci2.a.o, we have had no buildbots since late last year. I think most of our buildbot configs should be able to run on 3.2, except for svn-w2k3-local and svn-x64-macosx-dgvrs, so as a stopgap measure, I tried commenting the aforementioned two and activating the config by renaming [3] to remove the "-disabled" suffix. However, Gavin McDonald comments on INFRA-22761: "I'm afraid we still can not activate this config. There are no agents in which any of the builders can use at this point." Any ideas what we should do to get some buildbots back online? [1] https://issues.apache.org/jira/browse/INFRA-22277 [2] https://issues.apache.org/jira/browse/INFRA-22761 [3] https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/subversion.py Cheers, Nathan
RE: Windows build
-Original Message- From: Nathan Hartman Sent: Tuesday, March 15, 2022 4:21 PM To: Daniel Sahlberg Cc: Subversion Development Subject: Re: Windows build On Tue, Mar 15, 2022 at 11:10 AM Daniel Sahlberg wrote: > > Hi, > > I'm once again restarting my efforts on a solid Windows build environment. > I've been checking the scripts in build/win32 and believe these might be a > reasonable starting point. I still have a set of files to build Subversion and most dependencies as part of the SharpSvn build, which used to drive a few Windows buildbots as well. (I think they are still offline after the recent buildbot master upgrade). The scripts also allow building Subversion and its dependencies on GitHub actions. (The SlikSvn Subversion binaries are built on that environment). https://github.com/AmpScm/SharpSvn/ is the new canonical url, after moving away from open.collab.net. (dependency scripts are all in the imports subdirectory) I just upgraded the scripts there to build on Visual Studio 2022 (see r1899028 for the changes on the Subversion side) as that is now the default build environment on GitHub's 'windows-latest' actions. Bert
RE: Fwd: Can't create temporary file from template ... No such file or directory
We have helper functions for this scenario (svn_uri__*()) that also perform the required escaping rules (required for url, but not for relpath) Bert -Original Message- From: Stefan Sperling Sent: Monday, December 6, 2021 9:31 AM To: Nathan Hartman Cc: Subversion Developers Subject: Re: Fwd: Can't create temporary file from template ... No such file or directory On Sun, Dec 05, 2021 at 11:21:48PM -0500, Nathan Hartman wrote: > On Sun, Dec 5, 2021 at 12:55 PM James McCoy wrote: > > > > On Sun, Dec 05, 2021 at 12:41:30PM -0500, Nathan Hartman wrote: > > > It's not dumping core on mine. I would like to debug this properly > > > but am running into various nonsense. For example, I haven't > > > figured out how to run it under gdb since svn is being called > > > through the libtool script; > > > > "libtool exec gdb ./subversion/svn ..." will run svn with the > > environment setup properly. > > Perfect. That's the clue I needed. Thanks, James. > > At diff_dir_added() at libsvn_client/conflicts.c:7570 (in current > trunk, r1895609) we are attempting to concat some path components > with: > > copyfrom_url = apr_pstrcat(scratch_pool, b->repos_root_url, "/", > right_source->repos_relpath, > SVN_VA_NULL); > > However, right_source->repos_relpath is an empty string, so we end up > with b->repos_root_url plus a trailing slash, causing the path to > become non-canonical. > > The fix might be as simple as checking for that and not calling > apr_pstrcat(), but I would like to dig a little more before jumping to > conclusions. Thanks, Nathan. I see this is in the conflict resolver so this is probably code I have written. But I won't snag this away from you. And if you need any help, just let me know. (I have not yet looked into details; I suspect that right_source might be bogus or simply invalid?) Cheers, Stefan
Re: Buildbot Migration
Hi Gavin, I will see what I can do for the win32 Subversion bots. I recently upgraded them to a new VM, but it took some effort to get the old buildbot scripts up and running again. On Tue, Nov 9, 2021 at 12:07 PM Gavin McDonald wrote: > Hi All. > > Getting back to this : https://issues.apache.org/jira/browse/INFRA-22277 > > I'd like for the owner(s) of the mentioned nodes to upgrade and then > contact me so we can get them hooked up to the new controller. > > TY >
Re: Missing pilcrows (was: Re: SVN-4874: Avoid foreign repository merge if repository UUIDs) match
Historic note: A long time ago we had to be very strict not to do this, as some major Subversion hosting provider (of which I don't know the name) just copied a blank repository to create new repositories. So all repositories hosted there had the same UUID. (And they couldn't just 'fix' this, as that would immediately break other working copies) I really hope this comment is now long outdated and we can just enable this Bert On Mon, Apr 26, 2021 at 8:39 PM Daniel Shahaf wrote: > Thanks a lot for fixing these! And kudos for giving the case-by-case > details ☺ >
Re: svn commit: r1891416 - /subversion/site/staging/faq.html
Too bad both Neon and Serf support NTLM and SSPI for quite some time, so the reason is a bit outdated... But I would still recommend enabling that line, as there are quite some users that want to mix accounts and SSPI only allows you access with the one configured for NTLM/SSPI. On Fri, Jul 9, 2021 at 9:02 PM wrote: > Author: hartmannathan > Date: Fri Jul 9 19:02:01 2021 > New Revision: 1891416 > > URL: http://svn.apache.org/viewvc?rev=1891416=rev > Log: > * site/staging/faq.html: (#sspi): Fix typo: suppport -> support > > Modified: > subversion/site/staging/faq.html > > Modified: subversion/site/staging/faq.html > URL: > http://svn.apache.org/viewvc/subversion/site/staging/faq.html?rev=1891416=1891415=1891416=diff > > == > --- subversion/site/staging/faq.html (original) > +++ subversion/site/staging/faq.html Fri Jul 9 19:02:01 2021 > @@ -1717,7 +1717,7 @@ to see the section on SSPI authenticatio > > > Without this line, browsers that support SSPI will prompt for the > user's > -credentials, but clients that do not suppport SSPI such as Subversion > +credentials, but clients that do not support SSPI such as Subversion > will not prompt. (The current release of Neon - Subversion's HTTP > library - handles only basic authentication.) Because the client never > asks for credentials, any action that requires authentication will fail. > > >
Re: svn commit: r1890223 - /subversion/trunk/subversion/svn_private_config.hw
Most buildsystems on Windows assumed just Win32 and the usual win64-x64, and ARM64 is a different beast... An on top of that you usually cross compile. But I got confirmation that the binaries work great on these systems... It got through all the python+c tests except the 2 or 3 common failures we also see when setting up new bots. Bert Get Outlook for Android<https://aka.ms/AAb9ysg> From: Daniel Shahaf Sent: Thursday, May 27, 2021 7:50:13 PM To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r1890223 - /subversion/trunk/subversion/svn_private_config.hw b...@qqmail.nl wrote on Thu, 27 May 2021 11:51 +00:00: > We will need a few more patches to really support ARM64 builds. Once I > get things working I’ll add a pull request. Neither backport.pl nor backport.py support pull requests, so the RM would have to merge it manually. > Most likely I will release a SlikSvn client release for ARM64 with that > support if everything comes together… But cross compiling on Windows is > quite new for most of our dependencies, and ARM64 is new as well so > most dependencies need patches (except for those building via CMake) Is the relation between not needing patches and using CMake merely correlation or also causation? Cheers, Daniel
Re: svn commit: r1890674 - /subversion/branches/1.14.x/STATUS
He ran the Subversion + the SharpSvn tests on it without unexpected failures, so I will start delivering binaries for this new platform using these patches. Bert Get Outlook for Android<https://aka.ms/AAb9ysg> From: Nathan Hartman Sent: Thursday, June 10, 2021 6:55:07 PM To: Subversion Developers Subject: Re: svn commit: r1890674 - /subversion/branches/1.14.x/STATUS On Thu, Jun 10, 2021 at 5:49 AM wrote: > > Author: rhuijben > Date: Thu Jun 10 09:49:48 2021 > New Revision: 1890674 > > URL: http://svn.apache.org/viewvc?rev=1890674=rev > Log: > * STATUS: Nominate ARM64 support. > > Modified: > subversion/branches/1.14.x/STATUS > > Modified: subversion/branches/1.14.x/STATUS > URL: > http://svn.apache.org/viewvc/subversion/branches/1.14.x/STATUS?rev=1890674=1890673=1890674=diff > == > --- subversion/branches/1.14.x/STATUS (original) > +++ subversion/branches/1.14.x/STATUS Thu Jun 10 09:49:48 2021 > @@ -83,6 +83,13 @@ Candidate changes: > Votes: > +1: danielsh > > + * r1890223, r1890668, r1890673 > + Support building on Win64/ARM64. > + Justification: > + At user request (via SharpSvn) > + votes: > + +1: rhuijben I'm not sure how much support this backport proposal will get since the log for r1890673 says it is untested (for now). It would be helpful if (at least) the user who requested it could write and confirm that it's working for them. Nathan
RE: svn commit: r1890223 - /subversion/trunk/subversion/svn_private_config.hw
We will need a few more patches to really support ARM64 builds. Once I get things working I’ll add a pull request. Most likely I will release a SlikSvn client release for ARM64 with that support if everything comes together… But cross compiling on Windows is quite new for most of our dependencies, and ARM64 is new as well so most dependencies need patches (except for those building via CMake) Bert Van: Nathan Hartman Verzonden: woensdag 26 mei 2021 15:00 Aan: dev@subversion.apache.org Onderwerp: Re: svn commit: r1890223 - /subversion/trunk/subversion/svn_private_config.hw On Wed, May 26, 2021 at 8:31 AM mailto:rhuij...@apache.org> > wrote: Author: rhuijben Date: Wed May 26 12:31:05 2021 New Revision: 1890223 URL: http://svn.apache.org/viewvc?rev=1890223 <http://svn.apache.org/viewvc?rev=1890223=rev> =rev Log: * subversion/svn_private_config.hw Properly identify Windows on ARM/ARM64, instead of breaking the build. Modified: subversion/trunk/subversion/svn_private_config.hw Modified: subversion/trunk/subversion/svn_private_config.hw URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn_private_config.hw?rev=1890223 <http://svn.apache.org/viewvc/subversion/trunk/subversion/svn_private_config.hw?rev=1890223=1890222=1890223=diff> =1890222=1890223=diff == --- subversion/trunk/subversion/svn_private_config.hw (original) +++ subversion/trunk/subversion/svn_private_config.hw Wed May 26 12:31:05 2021 @@ -39,6 +39,10 @@ #define SVN_BUILD_TARGET "ia64-microsoft-windows" #elif defined( _M_IX86) #define SVN_BUILD_TARGET "x86-microsoft-windows" +#elif defined(_M_ARM64) +#define SVN_BUILD_TARGET "arm64-microsoft-windows" +#elif defined(_M_ARM) +#define SVN_BUILD_TARGET "arm-microsoft-windows" #else #error Unsupported build target. #endif This looks like it should be nominated for backport, though I don't have an ARM Windows machine to test with. Nathan
RE: svn commit: r1879198 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql
It looks like you get failures on this when you compile recent SQLite versions with OMIT_DEPRECATED. (I just bumped several dependencies on the Windows buildbot in an attempt to fix the python breakage) This should probably be backported... Bert -Oorspronkelijk bericht- Van: rhuij...@apache.org Verzonden: donderdag 25 juni 2020 19:12 Aan: comm...@subversion.apache.org Onderwerp: svn commit: r1879198 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql Author: rhuijben Date: Thu Jun 25 17:11:44 2020 New Revision: 1879198 URL: http://svn.apache.org/viewvc?rev=1879198=rev Log: Fix invalid escape sequence in working copy queries which causes upgrades from Subversion 1.7 working copies to fail with recent SQLite versions (>= 3.29.0). * subversion/libsvn_wc/wc-metadata.sql (STMT_UPGRADE_TO_30): Use '' to delimit values and "" to escape column names. Modified: subversion/trunk/subversion/libsvn_wc/wc-metadata.sql Modified: subversion/trunk/subversion/libsvn_wc/wc-metadata.sql URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc-metadata.sql?rev=1879198=1879197=1879198=diff == --- subversion/trunk/subversion/libsvn_wc/wc-metadata.sql (original) +++ subversion/trunk/subversion/libsvn_wc/wc-metadata.sql Thu Jun 25 17:11:44 2020 @@ -636,7 +636,7 @@ ON NODES (wc_id, moved_to, op_depth); CREATE INDEX IF NOT EXISTS I_PRISTINE_MD5 ON PRISTINE (md5_checksum); -UPDATE nodes SET presence = "server-excluded" WHERE presence = "absent"; +UPDATE nodes SET presence = 'server-excluded' WHERE presence = 'absent'; /* Just to be sure clear out file external skels from pre 1.7.0 development working copies that were never updated by 1.7.0+ style clients */
RE: SVN 1.14 release: please fix your buildbot
This buildbot runs python 2.X (and has for years) and now the tests are broken. I don't remember seeing changes to the actual Conflict handing code in Subversion itself, so... I still think this is related to the changes to the test framework causing regressions on 2.7. This buildbot does the testing on Windows with python 2.7... But errors on this bot are often ignored by *nix developers. (It reported errors for some weeks because build.conf was broken for Windows... and once that was fixed this new problem existed so 'nobody' noticed) -Oorspronkelijk bericht- Van: Yasuhito FUTATSUKI Verzonden: woensdag 6 mei 2020 13:19 Aan: dev@subversion.apache.org; b...@qqmail.nl Onderwerp: Re: SVN 1.14 release: please fix your buildbot On 2020/05/06 19:48, b...@qqmail.nl wrote: > The Windows buildbots currently produce actual errors, most likely > caused by recent changes to the python test framework. (It is > expecting to see \r, but now sees \n in several text conflicts) The reason of failures aren't recent changes of the python test framework, but no one cared of the tests on Windows with Python 3. Please see the thread "Problems running testsuite on Windows with Python 3" [1]. We are now working to try to fix it. [1] https://lists.apache.org/thread.html/r87a33f0046949fe59188e844832297d8a00e67 5c4e59a1ab01005e0e%40%3Cdev.subversion.apache.org%3E Cheers, -- Yasuhito FUTATSUKI /
RE: SVN 1.14 release: please fix your buildbot
The Windows buildbots currently produce actual errors, most likely caused by recent changes to the python test framework. (It is expecting to see \r, but now sees \n in several text conflicts) Bert -Oorspronkelijk bericht- Van: Stefan Sperling Verzonden: donderdag 2 april 2020 16:54 Aan: Bert Huijben ; Branko Čibej ; dev@subversion.apache.org Onderwerp: Re: SVN 1.14 release: please fix your buildbot On Mon, Mar 16, 2020 at 09:27:28AM +0100, Stefan Sperling wrote: > Hi Bert and Brane, > > Your windows-ra and macosx-apr1.3-nothread buildbots are currently failing. > > If possible please fix them, or retire them if they are no longer needed. > > For release management it would help us to have a set of only green > buildbots to start with, so we can easily identify any new problems > across all platforms that pop up during the release testing phase as > fixes get committed. > > Thanks, > Stefan Hi, Both buildbots are still failing. Unless someone can help out with getting these failures fixed, I will just have to ignore these problems and go ahead with rolling a new release anyway.
RE: Building SVN (dependencies) on Windows
Quite a few of the Windows dependencies can easily be built by the VCPKG package manager. For SharpSvn I maintained quite a few custom NAnt scripts that do about the same work (https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports (or <https://github.com/AmpScm/SharpSvn/tree/master/imports> https://github.com/AmpScm/SharpSvn/tree/master/imports, but I think this mirror lags a bit ) Somewhere in the CollabNet open source repositories there should be a slightly simpler -not as many development options- MSBuild version of the scripts to build the dependencies, but I’m not sure at which url. Bert Van: Graham Bloice Verzonden: donderdag 23 april 2020 18:17 Aan: dev@subversion.apache.org Onderwerp: Re: Building SVN (dependencies) on Windows Apologies for butting in, but as a long time maintainer of the (mainly Windows) build process for Wireshark, another cross platform project, I'd like to offer my thoughts on such matters to the svn project. 1. We moved to CMake quite some time ago, getting rid of automake and nmake and VS solution files. Such a relief to have one build tool, usable on all platforms. This is obviously a big step to take. 2. Wireshark has lots of dependencies on 3rd party libraries and on Windows the usual issues of obtaining them and where to put them. The project has "solved" this by maintaining an svn repo (even though the project has switched to git for the sources) of "-dev" zip packages containing the items required to build; headers, .lib and .dll files, e.g. https://anonsvn.wireshark.org/wireshark-win64-libs/trunk/packages/Part of the CMake generation step runs a PowerShell script that checks for updates, downloads the required zips and expands them to a "known" location, configurable by env vars. The locations of these files are passed as hints to the CMake findxxx modules (modified by the project) so that CMake is happy. Some build tools and libraries are exclude from this process and have to be manually installed, e.g. Perl, Python, Qt. 3. Production of the "-dev" packages takes a few forms, cross building on OpenSUSE or using vcpkg, the details are listed for each library, e.g. https://www.wireshark.org/docs/wsdg_html_chunked/ChLibsGLib.html. When a library is updated, a single "tag" file in the main source tree is updated causing all builders to check for changes. 4. All required artefacts are built\copied by CMake directives into the run-time directory so tests can be run without requiring installation. 5. The installers are also built by CMake and pick up the required artefacts from the run-time directory. I see a number of advantages with the Wireshark solution: 1. Much smaller barrier to entry for those attempting to build. Still quite a setup needed, hence the developer's guide step-by-step section, see here:https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html 2. No need to build (or even download unless there are changes) the 3rd party libraries reducing build times 3. Consistency across builds for all users, no local variations causing oddities. You can see the sausages being made over at the Wireshark buildbot: https://buildbot.wireshark.org/wireshark-master/waterfall, in particular the "ran CMake" generation step, although if there are no updates to the libraries it's a standard CMake experience. I'm not subscribed to the list, just observe infrequently via the svn.haxx.se <http://svn.haxx.se> archive, so if you have any questions please add me in replies. P.S. I did build svn on Windows once, many years ago and I found it an awkward process. -- Graham Bloice
RE: Svnmucc sensitive to order of mkdir
1.8.15 just orders the operations based on path, so you may be lucky that it works, but there are a lot of other examples where pre 1.9 fail caused by the simplicity of the code there. (Thinks like renaming directories and then applying operations). With 1.9 there is a backing framework that should allow options like –parent to be added without too much hassle. (I know the path exists check that knows the previously scheduled operations is there… It is probably the reason your example of adding a directory before its parent fails). I think parsing the commandline with optional flags might be the hardest part here, as svnmucc doesn’t have such options on subcommands yet as far as I know. Bert Van: 钱海远(Nathan) Verzonden: dinsdag 28 april 2020 14:45 Aan: dev@subversion.apache.org Onderwerp: Svnmucc sensitive to order of mkdir Dear all, I <mailto:dev@subversion.apache.org> was discuss with Daniel Shahaf about the Issue: https://issues.apache.org/jira/browse/SVN-4854 SVN 1.10.6 change the svnmucc , it’s sensitive with mkdir operations, if a want to mkdir /foot/bar when /foot is not exists , svnmucc only can work with svnmucc mkdir ‘/foor’ mkdir ‘/foot/bar’ . Cannot work with svnmucc mkdir ‘/foot/bar’ mkdir ‘/foot’. But it’s both success with 1.8.15 version. Daniel Shahaf told me the new subversion is much more sensitive to order of operation. So, can we set the option --parent with svnmucc mkdir? _ Best Regards! Haiyuan Qian R & D Management Group Hangzhou Hikvision Digital Technology Co.,Ltd No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China M (86)18969199712 本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _ CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com <http://www.hikvision.com>
Re: svn commit: r1874093 - in /subversion/trunk/subversion: libsvn_subr/cmdline.c tests/cmdline/update_tests.py
I think this needs a specific implementation for Windows. The rules on
Windows are different and not really tied to some shell.
Applications receive the full commandline as string and then need to parse
them themselves. Usually they leave this to the C library so there are some
rules that are pretty common, but there are always exceptions.
For most programs it is best to start by escaping arguments that have some
special characters (such as whitespace)using quotes. Within quotes only
other quotes and backslashes next to quotes need further escaping
On Windows the current test fails with
[[
W: DIFF STDOUT (match_all=True):
W: | --- EXPECTED STDOUT (match_all=True)
W: | +++ ACTUAL STDOUT
W: | @@ -1,6 +1,9 @@
W: | Updating 'svn-test-work\working_copies\update_tests-38.backup\A\D\G\p; i':
W: | Csvn-test-work\working_copies\update_tests-38.backup\A\D\G\p; i
W: | Updated to revision 3.
W: | +usage: svneditor.py file
W: | + svneditor.py base theirs mine merged wc_path
W: | +arguments passed were:
['D:\\ra\\svn-ra\\build\\subversion\\tests\\cmdlinesvneditor.py',
'p\\;\\', 'i']
W: | Merge conflicts in
'svn-test-work\working_copies\update_tests-38.backup\A\D\G\p; i'
marked as resolved.
W: | Summary of conflicts:
W: |Text conflicts: 0 remaining (and 1 already resolved)
W: CWD: E:\svn-ra\tests\subversion\tests\cmdline
]]
(See
https://ci.apache.org/builders/svn-windows-ra/builds/2871/steps/Test%20fsfs%2Bsvn/logs/faillog
)
Using ';' on a path works on Windows, but is certainly not recommended. It
is the path separator used in environment variables like %PATH%.
Bert
On Mon, Feb 17, 2020 at 3:13 AM wrote:
> Author: jamessan
> Date: Mon Feb 17 02:13:34 2020
> New Revision: 1874093
>
> URL: http://svn.apache.org/viewvc?rev=1874093=rev
> Log:
> Followup to r1874057, escape whitespace instead of quoting filename
>
> As danielsh pointed out, only specific characters can be escaped by a
> backslash
> in quoted shell strings. Rather than surrounding the escaped path with
> double
> quotes, post-process the quoted path and manually escape any whitespace
> that is
> present.
>
> * subversion/libsvn_subr/cmdline.c
> (escape_path): New function, wrapper around apr_pescape_shell(), which
>handles escaping of whitespace.
> (svn_cmdline__edit_file_externally, svn_cmdline__edit_string_externally):
>Call the new function instead of apr_pescape_shell()
> * subversion/tests/cmdline/update_tests.py
> (update_accept_conflicts): Include ';' in renamed path ("p; i"), to
> ensure
>non-whitespace escaping is handled correctly.
>
> Modified:
> subversion/trunk/subversion/libsvn_subr/cmdline.c
> subversion/trunk/subversion/tests/cmdline/update_tests.py
>
> Modified: subversion/trunk/subversion/libsvn_subr/cmdline.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/cmdline.c?rev=1874093=1874092=1874093=diff
>
> ==
> --- subversion/trunk/subversion/libsvn_subr/cmdline.c (original)
> +++ subversion/trunk/subversion/libsvn_subr/cmdline.c Mon Feb 17 02:13:34
> 2020
> @@ -1234,7 +1234,7 @@ svn_cmdline__be_interactive(svn_boolean_
> }
>
>
> -/* Helper for the next two functions. Set *EDITOR to some path to an
> +/* Helper for the edit_externally functions. Set *EDITOR to some path to
> an
> editor binary. Sources to search include: the EDITOR_CMD argument
> (if not NULL), $SVN_EDITOR, the runtime CONFIG variable (if CONFIG
> is not NULL), $VISUAL, $EDITOR. Return
> @@ -1300,6 +1300,42 @@ find_editor_binary(const char **editor,
>return SVN_NO_ERROR;
> }
>
> +/* Wrapper around apr_pescape_shell() which also escapes whitespace. */
> +static const char *
> +escape_path(apr_pool_t *pool, const char *orig_path)
> +{
> + apr_size_t len, esc_len;
> + const char *path;
> + char *p, *esc_path;
> +
> + path = apr_pescape_shell(pool, orig_path);
> +
> + len = esc_len = 0;
> +
> + /* Now that apr has done its escaping, we can check whether there's any
> + whitespace that also needs to be escaped. This must be done after
> the
> + fact, otherwise apr_pescape_shell() would escape the backslashes
> we're
> + inserting. */
> + for (p = (char *)path; *p; p++)
> +{
> + len++;
> + if (*p == ' ' || *p == '\t')
> +esc_len++;
> +}
> +
> + if (esc_len == 0)
> +return path;
> +
> + p = esc_path = apr_pcalloc(pool, len + esc_len + 1);
> + while (*path)
> +{
> + if (*path == ' ' || *path == '\t')
> +*p++ = '\\';
> + *p++ = *path++;
> +}
> +
> + return esc_path;
> +}
>
> svn_error_t *
> svn_cmdline__edit_file_extern
Re: Change to Subversion PMC rule for approving backports
+1 Thanks Julian! On Tue, Sep 17, 2019 at 5:11 PM Branko Čibej wrote: > On 17.09.2019 16:53, Julian Foad wrote: > > Bert Huijben wrote: > >>>>> +1 on reducing the number of required votes to just 2 +1s. > > > > We have consensus in this thread for reducing the requirement for > > regular (non-LTS) releases to two "+1" votes, but not to just one. > > Thanks for pushing this through, Julian. > > -- Brane > >
Re: [PATCH] test-deps += svnmover
Why can't this be fixed via the build.conf file? I think it can just be added to the [__ALL_TESTS__] group instead of hardcoding it in python. svnauthz is probably an exception as it is related to a symlink. Bert On Mon, Sep 2, 2019 at 4:24 PM Julian Foad wrote: > Daniel Shahaf wrote: > > In current master, «./autogen.sh && ./configure && make davautocheck» > fails all svnmover tests. > > By default, 'make davautocheck' expects to find > 'tools/server-side/mod_dontdothat' has already been built; my first > reaction then was to run 'make tools' which builds that and also builds > 'svnmover', and the tests pass; but if I instead run 'make > mod_dontdothat' then I see the problem. > > > make davautocheck > > I think the following will fix it, but haven't verified: > > > > Index: build/generator/gen_base.py > > === > > --- build/generator/gen_base.py (revision 1866222) > > +++ build/generator/gen_base.py (working copy) > > @@ -663,7 +663,7 @@ class TargetExe(TargetLinked): > > TargetLinked.add_dependencies(self) > > > > # collect test programs > > -if 'svnauthz' in self.name: # special case > > +if 'svnauthz' in self.name or 'svnmover' in self.name: # special > case > > self.gen_obj.test_deps.append(self.filename) > > self.gen_obj.test_helpers.append(self.filename) > > elif self.install == 'test': > > > > Could someone please verify/commit? > > Verified and committed: http://svn.apache.org/r1866281 > > Thanks for finding that. > > - Julian > > >
Re: Change to Subversion PMC rule for approving backports
Why just one +1? I like the second eye rule we currently have, so one +1 from the nominator and one additional eye. For bindings we have +- the same rule, but one of the eyes can be someone else than a full committer. (Not sure if we still have any active partial committers though) As always, feel free to ping me if you need an additional review for something. I don't follow the dev@ list on a daily basis any more :( +1 on reducing the number of required votes to just 2 +1s. Bert On Thu, Aug 29, 2019 at 5:36 PM Julian Foad wrote: > To all devs: > > Proposal for a permanent change to our backport rules [1]: > >* For non-LTS releases, each backport nomination only requires one +1 > vote (instead of three). > > Specific diff to the text of [1]: > > - A change needs three +1 votes from full committers (or partial > committers for the involved areas), and no vetoes, to go into A.B.x. > + A change needs three +1 votes (for an LTS release line) or one +1 vote > (for a non-LTS release line) from full committers (or partial committers > for the involved areas), and no vetoes, to go into A.B.x. > > - (If a change affects the build system, however, it is considered a > core change, and needs three +1's.) > + (If a change affects the build system, however, it is considered a > core change, and so for an LTS release line needs three +1's.) > > Agreements? > > > [1] > > http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization > > - Julian > > > > Branko Čibej wrote: > > On 18.07.2019 14:09, Julian Foad wrote: > >> Recently there have not been enough developers willing and able to > >> test and approve proposed fixes for back-port to the supported release > >> branches. > >> > >> We have just been discussing this on #svn-dev [1]. Rather than delay > >> forever, myself, stsp and brane decided that in line with "silence > >> implies consent", we can go ahead with merging the proposed backports > >> even if they have fewer than 3 votes. > >> > >> We will go ahead now. > > > > Thanks for the heads-up, Julian, and for pushing the releases. [...] >
Re: Windows build error introduced in revision 1850611
Hi, I happened to find this issue myself today, short before your message was moderated through. I applied a fix to build.conf in r1851462, which should fix the problem. (It is currently being tested by our buildbot). Thanks, Bert On Wed, Jan 16, 2019 at 5:04 PM Alexander Miloslavskiy < alexandr.miloslavs...@gmail.com> wrote: > Hello, > > I'm not subscribed, please CC me in answers. > > For reference, build error text: > svndumpfilter.obj : error LNK2001: unresolved external symbol > svn_relpath__make_internal > [...\build\win32\vcnet-vcproj\svndumpfilter.vcxproj] > > In revision 1850611 function was moved to new header > svn_dirent_uri_private.h which wasn't properly added to 'build.conf'. > This causes the generated 'libsvn_subr.def' file to not export the > function, which in turns causes 'unresolved external symbol'. > > Please fix this by adding 'private\svn_dirent_uri_private.h' near line > 370 in 'build.conf'. > > Thanks! >
Re: Blame callback: remove start/end parameters
Not sure if that would be as helpful as the old code and/or can be done with a compatibility wrapper. The problem is that the output arguments are available only, long after the blame reporting is done, while with the current implementation intermediate callbacks can be used more efficiently. Perhaps if we document that the output arguments are set before the first invocation of the callback, but that would be an API-first. Bert On Tue, Jan 15, 2019 at 1:30 AM Johan Corveleyn wrote: > On Mon, Jan 14, 2019 at 4:13 PM Julian Foad wrote: > > > > Julian Foad wrote: > > > The svn_client_blame_receiver4_t parameters "start_revnum" and > > > "end_revnum" do not really belong here because they are not per-line > > > data. They are the "resolved" versions of the input revnums to > > > svn_client_blame6(). I introduced them in r955895, applying a patch by > > > Johan. I propose to move them to svn_client_blame6() output parameters. > > Ooh, my very first patch :-). I had no clue what I was doing back > then, and I still don't most of the time :-). Thanks for improving > things ... > > -- > Johan >
Re: svn commit: r1850781 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/blame.c libsvn_client/deprecated.c
As far as I can tell blame handles all svn:eol-style values, which can be a
simple 'CR' in which case the normalized form has a plain '\r'. (Only in
case of native and 'LF' the normalized form is a single '\n') Are we sure
this case is properly handled now?
(I read a comment that this is just stripped now)
Bert
On Tue, Jan 8, 2019 at 8:41 PM Stefan Kueng wrote:
>
>
> On 08.01.2019 20:30, Michael Pilato wrote:
> >> On 08.01.2019 19:45, stevek...@apache.org wrote:
> >>> Author: steveking
> >>> Date: Tue Jan 8 18:45:45 2019
> >>> New Revision: 1850781
> >
> > [...]
> >
> >>> Modified: subversion/trunk/subversion/include/svn_client.h
> >>> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_client.h?rev=1850781=1850780=1850781=diff
> >>>
> ==
> >>> --- subversion/trunk/subversion/include/svn_client.h (original)
> >>> +++ subversion/trunk/subversion/include/svn_client.h Tue Jan 8
> 18:45:45 2019
> >>> @@ -736,10 +736,11 @@ typedef svn_error_t *(*svn_client_get_co
> >>> * @{
> >>> */
> >>>
> >>> -/** Callback type used by svn_client_blame5() to notify the caller
> >>> +/** Callback type used by svn_client_blame6() to notify the caller
> >>> * that line @a line_no of the blamed file was last changed in @a
> revision
> >>> * which has the revision properties @a rev_props, and that the
> contents were
> >>> - * @a line.
> >>> + * @a line. The @a line content is delivered as is. It is up to the
> client to
> >>> + * determine the encoding. The line does not contain the cr/lf at the
> end.
> >
> > Minor nit: please use all-caps "CR" and "LF" in this context.
>
> Done.
>
> Stefan
>
Re: Subversion Exception!
+svn_error_t *
+svn_error__malfunction_f(svn_boolean_t can_return,
+ const char *file, int line,
+ const char *fmt, ...)
+{
+ apr_pool_t *pool = svn_pool_create(NULL);
+ va_list ap;
+ const char *expr;
+
+ va_start(ap, fmt);
+ expr = apr_pvsprintf(pool, fmt, ap);
+ va_end(ap);
+ return malfunction_handler(can_return, file, line, expr);
+}
+
Can we somehow use a smarter pool (perhaps just require passing an existing
scratch pool as some similar apr apis do). Some library users do use the
can_return feature and/or exception handling and we would introduce a minor
memory leak.
Further +1
Bert
On Thu, Dec 13, 2018 at 4:05 PM Julian Foad wrote:
> Johan Corveleyn wrote:
> > Just thinking out loud here, but could we perhaps log the
> > non-canonical value as part of the assertion output?
> > [...]
> > something like
> >
> > line 10238: assertion failed
> > (svn_dirent_is_absolute(local_abspath='C:ImNotCanonical'))
>
> Yes, Johan, we could do that.
>
> The attached patch demonstrates it working.
>
> Test output:
> [[[
> $ subversion/tests/libsvn_wc/wc-test 1
> ...
> svn_tests: E235000: In file '.../subversion/libsvn_wc/wc_db.c' line 10238:
> assertion failed (svn_dirent_is_absolute(local_abspath='C:ImNotAbsolute'))
> ...
> ]]]
>
> --
> - Julian
>
Re: svn commit: r1845066 - /subversion/trunk/notes/dump-load-format.txt
This actually depends on what APR uses on different machines. We (as Subversion) fully depend on APR to generate the UUID, and different platforms may (and will) use different techniques. APR has its own fallback completely depending on date/time+randomness when a platform doesn't provide its own UUID api. On Windows XP and later, the UuidCreate() function implementing this function for us doesn't encode the MAC. On older (now unsupported) windows versions it did encode it. I'm not sure if this kind of implementation detail belongs in the documentation. Bert On Sun, Oct 28, 2018 at 10:14 PM, wrote: > Author: esr > Date: Sun Oct 28 21:14:03 2018 > New Revision: 1845066 > > URL: http://svn.apache.org/viewvc?rev=1845066=rev > Log: > * notes/dump-load-format.txt: More about uuid format > > Modified: > subversion/trunk/notes/dump-load-format.txt > > Modified: subversion/trunk/notes/dump-load-format.txt > URL: http://svn.apache.org/viewvc/subversion/trunk/notes/dump- > load-format.txt?rev=1845066=1845065=1845066=diff > > == > --- subversion/trunk/notes/dump-load-format.txt (original) > +++ subversion/trunk/notes/dump-load-format.txt Sun Oct 28 21:14:03 2018 > @@ -72,6 +72,10 @@ UUID: > where the is the UUID of the originating repository. > An example UUID is "7bf7a5ef-cabf-0310-b7d4-93df341afa7e". > > +As generated by Subversion, these UUIDs are "Version 1", incorporating > +the MAC of the originating machine. The presentation is in RFC4122 > +form without the "urn:" or "uuid:" prefixes. > + > Revision records > > A Revision record has three headers and is usually followed by a > > >
Re: [PATCH] Proof of concept of the better-pristines (LZ4 + storing small pristines as BLOBs) (Was: Re: svn commit: r1843076)
On Windows' NTFS implementation very small files (probably something like <
256 bytes, but this is not documented/strictly stable) are stored in the
directory table and so don't use 'a whole cluster'.
Nice work on all the research!
Bert
On Tue, Oct 23, 2018 at 6:12 PM, Branko Čibej wrote:
> On 22.10.2018 22:14, Evgeny Kotkov wrote:
> > Branko Čibej writes:
> >
> >> Still missing is a mechanism for the libsvn_wc (and possibly
> >> libsvn_client) to determine the capabilities of the working copy at
> >> runtime (this will be needed for deciding whether to use compressed
> >> pristines).
> > FWIW, I tried the idea of using LZ4 to compress the pristines and
> storing small
> > pristines as blobs in the `PRISTINE` table. I was particularly
> interested in
> > how such change would affect the performance and what kind of obstacles
> > would have to be dealt with.
>
> Nice! I did some simpler tests by compressing exported trees, but this
> is definitely better.
>
> > In the attachment you will find a more or less functional implementation
> of
> > this idea that might be useful to some extent. The patch is a proof of
> > concept: it doesn't include the WC compatibility bits and most certainly
> > doesn't have everything necessary in place. But in the meanwhile, I
> think
> > that is might give a good approximation of what can be expected from the
> > approach.
> >
> > The patch applies to the `better-pristines` branch.
> >
> > A couple of observations:
> >
> > - As expected, the combined size of the pristines is halved when the
> data
> >itself is compressible, thus making the working copy 25% smaller.
>
> Yes, that was my observation as well. In fact, though, storing small
> BLOBs in the database itself should have even better effects, since the
> space on disk actually used by a file is rounded up to the nearest
> cluster size, but SQLite's blocks are typically much smaller than that.
>
>
> > - A variety of the callers currently access the pristine contents by
> reading
> >the corresponding files. That doesn't work in case of compressed
> pristines
> >or pristines stored as BLOBs.
> >
> >I think that ideally we would want to use streams as much as
> possible, and
> >only spill the uncompressed pristine contents to temporary files when
> we
> >need to pass them to external tools, etc.; and that temporary files
> need
> >to be backed by a work queue to avoid leaving them in place in case
> of an
> >application crash.
>
> Yes and yes. Keeping those temporary spilled files on disk could turn
> out to be a problem, finding a reasonable time to delete them without
> having to run cleanup will be rather important, I think.
>
>
> >The patch does that kind of plumbing to some extent, but that part of
> the
> >work is not complete. The starting point is around wc_db_pristine.c:
> >svn_wc__db_pristine_get_path().
> >
> > - Using BLOBs to store the pristine contents didn't have a measurable
> impact
> >on the speed of the WC operations such as checkout in my experiments
> on
> >Windows. These experiments were not comprehensive, and also I didn't
> run
> >the tests on *nix.
>
> I wouldn't expect much change in performance but would expect better use
> of the disk, as explained above.
>
> > - There's also the deprecated svn_wc_get_pristine_copy_path() public
> API that
> >would require plumbing to maintain compatibility; the patch performs
> it by
> >spilling the pristine contents result into a temporary file whose
> lifetime
> >is attached to the `result_pool`.
>
> Ack; that's one reasonable definition of "lifetime." But I suspect that
> any users of that function expect the pristine file to survive at least
> to the next WC cleanup.
>
> > (I probably won't be able to continue the work on this patch in the
> nearby
> > future; posting this in case it might be useful.)
>
> Thanks, it definitely is useful!
>
> -- Brane
>
>
Re: Subversion Exception on commit wirth pathfile
Could you try this same operation with the disk names capitalized? If this resolves the issue, please let us and the TortoiseSVN developers know, as in that case there is an issue in (their) path canonicalization api. Bert On Thu, Oct 18, 2018 at 12:13 PM Johan Corveleyn wrote: > On Thu, Oct 18, 2018 at 11:34 AM Yakov Maryanov wrote: > > > > Hello! > > > > I execute command: > > > > "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:commit > /pathfile:"d:\SVN\Work\Source\Project\f2.txt" > > > > File f2.txt contains two strings: > > > > d:\SVN\Work\Source\Source\Project.Client > > d:\SVN\Work\Source\Source\Project.Server > > > > And I received such result: > > > > --- > > Subversion Exception! > > --- > > Subversion encountered a serious problem. > > Please take the time to report this on the Subversion mailing list > > with as much information as possible about what > > you were trying to do. > > But please first search the mailing list archives for the error message > > to avoid reporting the same problem repeatedly. > > You can find the mailing list archives at > > https://subversion.apache.org/mailing-lists.html > > > > Subversion reported the following > > (you can copy the content of this dialog > > to the clipboard using Ctrl-C): > > > > In file > > > 'D:\Development\SVN\Releases\TortoiseSVN-1.10.2\ext\subversion\subversion\libsvn_wc\wc_db.c' > > line 10238: assertion failed (svn_dirent_is_absolute(local_abspath)) > > --- > > OK > > --- > > > > Am I doing something wrong, or is this a bug? > > Hi Yakov, > > This might be a problem specific to "TortoiseSVN", and not in "core > svn". This mailinglist is for discussing the development of the core > svn functionality (the Apache Subversion project), so we don't know > anything about TortoiseProc.exe and how it handles its arguments etc > (eventually calling the underlying SVN libraries). So I suggest you > report this to one of the specific TortoiseSVN mailinglists. See > https://tortoisesvn.net/community.html. > > Thanks, > -- > Johan >
Re: svn commit: r1843888 - in /subversion/trunk/subversion: libsvn_client/copy.c tests/cmdline/copy_tests.py
I'm guessing this is an easy fix/patch for backporting to the supported
releases.
Anybody willing to check+nominate?
Bert
On Mon, Oct 15, 2018 at 10:55 AM wrote:
> Author: brane
> Date: Mon Oct 15 08:55:55 2018
> New Revision: 1843888
>
> URL: http://svn.apache.org/viewvc?rev=1843888=rev
> Log:
> Correctly handle existing parent directories during repository-to-WC copy.
>
> * subversion/libsvn_client/copy.c
> (repos_to_wc_copy): If add_parents flag is set and destination parent
>directory exists, but is unversioned, put it under version control.
>WC-to-WC copy behaves this way, and so should repos-to-WC copy.
>
> * subversion/tests/cmdline/copy_tests.py
> (copy_make_parents_wc_wc_existing_unversioned_dst,
>copy_make_parents_repo_wc_existing_unversioned_dst): Check behaviour
>with existing. unversioned destination directory for both repos-to-WC
>and WC-to-WC cases.
>
> Patch by: Nikita Slyusarev
> Fixes #4768
>
> Modified:
> subversion/trunk/subversion/libsvn_client/copy.c
> subversion/trunk/subversion/tests/cmdline/copy_tests.py
>
> Modified: subversion/trunk/subversion/libsvn_client/copy.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/copy.c?rev=1843888=1843887=1843888=diff
>
> ==
> --- subversion/trunk/subversion/libsvn_client/copy.c (original)
> +++ subversion/trunk/subversion/libsvn_client/copy.c Mon Oct 15 08:55:55
> 2018
> @@ -2742,6 +2742,16 @@ repos_to_wc_copy(svn_boolean_t *timestam
>SVN_ERR(svn_client__make_local_parents(dst_parent, TRUE, ctx,
> iterpool));
> }
> + else if (make_parents && dst_parent_kind == svn_node_dir)
> +{
> + SVN_ERR(svn_wc_read_kind2(_parent_kind, ctx->wc_ctx,
> dst_parent,
> +FALSE, TRUE, iterpool));
> + if (dst_parent_kind == svn_node_none)
> +{
> + SVN_ERR(svn_client__make_local_parents(dst_parent, TRUE,
> ctx,
> + iterpool));
> +}
> +}
>else if (dst_parent_kind != svn_node_dir)
> {
>return svn_error_createf(SVN_ERR_WC_NOT_WORKING_COPY, NULL,
>
> Modified: subversion/trunk/subversion/tests/cmdline/copy_tests.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/copy_tests.py?rev=1843888=1843887=1843888=diff
>
> ==
> --- subversion/trunk/subversion/tests/cmdline/copy_tests.py (original)
> +++ subversion/trunk/subversion/tests/cmdline/copy_tests.py Mon Oct 15
> 08:55:55 2018
> @@ -3504,6 +3504,50 @@ def copy_make_parents_wc_wc(sbox):
> expected_output,
> expected_status)
>
> +
> +#--
> +# Test copying and creating parents in the wc with dst directory being
> +# precreated and unversioned
> +
> +def copy_make_parents_wc_wc_existing_unversioned_dst(sbox):
> + "svn cp --parents WC_PATH WC_PATH (ex. unver. dst)"
> +
> + sbox.build()
> + wc_dir = sbox.wc_dir
> +
> + iota_path = sbox.ospath('iota')
> + new_iota_path = sbox.ospath('X/Y/Z/iota')
> + os.makedirs(os.path.dirname(new_iota_path))
> +
> + # Copy iota
> + svntest.actions.run_and_verify_svn(None, [],
> + 'cp', '--parents',
> + iota_path, new_iota_path)
> +
> + # Create expected output
> + expected_output = svntest.wc.State(wc_dir, {
> +'X' : Item(verb='Adding'),
> +'X/Y': Item(verb='Adding'),
> +'X/Y/Z' : Item(verb='Adding'),
> +'X/Y/Z/iota' : Item(verb='Adding'),
> +})
> +
> + # Create expected status tree
> + expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
> +
> + # Add the moved files
> + expected_status.add({
> +'X' : Item(status=' ', wc_rev=2),
> +'X/Y' : Item(status=' ', wc_rev=2),
> +'X/Y/Z' : Item(status=' ', wc_rev=2),
> +'X/Y/Z/iota' : Item(status=' ', wc_rev=2),
> +})
> +
> + svntest.actions.run_and_verify_commit(wc_dir,
> +expected_output,
> +expected_status)
> +
> +
> #--
> # Test copying and creating parents from the repo to the wc
>
> @@ -3546,6 +3590,49
Re: conflicts-test very slow over svnserve (Windows)
It resolves to both ::1 and 127.0.0.1 on Windows, and as (per RFC) ipv6 is tried before ipv4... things timeout before trying the address used by default (hardcoded) in svnserve. (We used to default to ipv6 for some time... But we decided to explicitly default to ipv4 when not passing the later added -6) More recent Windows versions have a workaround/speedup for this problem. They will swap the DNS results after a few failed attempts. Bert On Tue, Oct 2, 2018 at 4:30 PM Branko Čibej wrote: > On 02.10.2018 02:38, Johan Corveleyn wrote: > > I haven't looked deeply into it yet, but it seems that the > > conflicts-tests (the C tests) are very slow when testing over > > svnserve. I noticed this while testing 1.11.0-rc2, but I see the same > > with trunk and with 1.10.x. > > > > Running the entire conflicts-test.exe (on a ramdisk): > > - ra_local: 23s > > - ra_serf: 70s > > - ra_svn: 982s (16m22s) > > > > The difference between ra_local and ra_serf strikes me as normal > > (after all, the conflict resolver contacts the repository a lot to > > fetch information). The time of ra_svn not really :-). > > > > The slowdown seems to be spread over all the tests of conflicts-test > > (the dots of the test progress come evenly spread). > > > > Is anyone else seeing this? Only on Windows, or on *nix too? > > A performance problem with tree conflict resolution specific to svnserve? > > How do you set the URL for win-tests.py? I've noticed that using > svn://localhost is orders of magnitude slower than svn://127.0.0.1, > apparently because the Windows resolver attempts a DNS search for > 'localhost' first (and failing) before resolving it locally. > > -- Brane > >
Re: conflicts-test very slow over svnserve (Windows)
This could be related to log requests that are not somehow limited (by last rev and/or number of results). ra_serf and ar_local allow cancelling halfway through, while ra_svn doesn't. (No time to investigate this myself righ now) Bert On Tue, Oct 2, 2018 at 2:38 AM Johan Corveleyn wrote: > I haven't looked deeply into it yet, but it seems that the > conflicts-tests (the C tests) are very slow when testing over > svnserve. I noticed this while testing 1.11.0-rc2, but I see the same > with trunk and with 1.10.x. > > Running the entire conflicts-test.exe (on a ramdisk): > - ra_local: 23s > - ra_serf: 70s > - ra_svn: 982s (16m22s) > > The difference between ra_local and ra_serf strikes me as normal > (after all, the conflict resolver contacts the repository a lot to > fetch information). The time of ra_svn not really :-). > > The slowdown seems to be spread over all the tests of conflicts-test > (the dots of the test progress come evenly spread). > > Is anyone else seeing this? Only on Windows, or on *nix too? > A performance problem with tree conflict resolution specific to svnserve? > > -- > Johan >
Re: svn commit: r1839703 - /subversion/trunk/subversion/tests/cmdline/svnadmin_tests.py
The way we used to fix these issues in the past was using a bit of C code to fill in the gaps of python support, but I currently lack the time to implement this. (We had this problem with wc-ng in the past). I'd rather see a green build with a few skips than no change when new regressions are introduced. (Perhaps we should mark it XFail on the condition though) I'm currently not able to fix this issue on the Windows buildbots as in all distributions I know Python 2.7.x is build with its own SQLite, which is not new enough. I would have to build my own python, or jump to python 3.x, which most likely breaks on all legacy Subversion versions as I don't think anybody on Windows tests with Python 3.x yet. Bert On Thu, Aug 30, 2018 at 11:44 PM, Daniel Shahaf wrote: > rhuij...@apache.org wrote on Thu, 30 Aug 2018 21:18 +: > > Author: rhuijben > > Date: Thu Aug 30 21:18:31 2018 > > New Revision: 1839703 > > > > URL: http://svn.apache.org/viewvc?rev=1839703=rev > > Log: > > Mark 2 tests as skipped when we test using an python that contains > > an sqlite that is unable to read our sqlite db files. > > > > * subversion/tests/cmdline/svnadmin_tests.py > > (imports): Add wc, to use existing checker, as used in other places. > > (recover_prunes_rep_cache_when_enabled, > >recover_prunes_rep_cache_when_disabled): Add skip markers. > > > +++ subversion/trunk/subversion/tests/cmdline/svnadmin_tests.py > > @@ -3897,6 +3898,7 @@ def check_recover_prunes_rep_cache(sbox, > > > > @Issue(4077) > > @SkipUnless(svntest.main.is_fs_type_fsfs) > > +@SkipUnless(svntest.wc.python_sqlite_can_read_wc) > > def recover_prunes_rep_cache_when_enabled(sbox): > >"recover prunes rep cache when enabled" > >sbox.build() > > @@ -3905,6 +3907,7 @@ def recover_prunes_rep_cache_when_enable > > > > @Issue(4077) > > @SkipUnless(svntest.main.is_fs_type_fsfs) > > +@SkipUnless(svntest.wc.python_sqlite_can_read_wc) > > def recover_prunes_rep_cache_when_disabled(sbox): > >"recover prunes rep cache when disabled" > >sbox.build() > > I think you'll want to add these to the r1838813 backport nomination on > 1.9 and 1.10... > > But I'm not sure I like these skips. These tests, I believe, exist to > ensure that we don't introduce a "time bomb" configuration --- a fs > state that may lead to silent data loss down the road. I don't think > silently skipping these tests is a good idea. We _should_ be > verifying that the bug that we fixed (for the second time) in r1838813 > remains fixed. > > I am unable to suggest an alternative that meets both my goals and > your goals because the log message does not explain the reason for > the change. (Is this about the SQLite minimum version again? If so, > wouldn't relaxing the minimum to whatever 1.9 required --- that being > the first minor release that shipped FSFS f7 --- suffice?) > > Cheers, > > Daniel >
Re: [PATCH] Re: "svn diff" doesn't work correctly if a file is replaced with a symlink locally
For git style patches there is some magic that also allows creating
symlinks via the file mode. I think we have some test cases on that
behavior. you might be able to use this for building a regression test for
this case.
Bert
On Thu, Jul 19, 2018 at 8:51 PM, Daniel Shahaf
wrote:
> Dmitry Pavlenko wrote on Thu, Jul 19, 2018 at 19:03:30 +0200:
> > I'm attaching a reproducing test.
> >
>
> Thanks for the test!
>
> > I'm not 100% sure that
> >
> > [
> > 'Index: %s\n' % sbox.path('iota'),
> > '===
> \n',
> > '--- %s\t(revision 1)\n' % sbox.path('iota'),
> > '+++ %s\t(working copy)\n' % sbox.path('iota'),
> > '@@ -1 +1 @@\n',
> > '-This is the file \'iota\'.\n',
> > '+link iota\n',
> > '\ No newline at end of file\n',
> > '\n',
> > 'Property changes on: iota\n',
> > '___
> \n',
> > 'Added: svn:special\n',
> > '## -0,0 +1 ##\n',
> > '+*\n',
> > '\ No newline at end of property\n',
> > ]
> >
> > is the expected output but definitely the diff command shouldn't fail
> with
> > exit code 1 as it does now.
>
> There isn't a patch flying around that produces this output, right?
>
> In this case, I suggest that we add a regression test that simply expects
> any
> output and exit code zero — that's «run_and_verify_svn(svntest.
> verify.AnyOutput,
> [], 'diff', wc_dir)» — and add a comment reminding us to write a more
> explicit
> expectation once the issue is fixed. This would make sure the patch start
> passing as soon as we change the behaviour, even if the expected output
> predicted is a little off.
>
> > +++ subversion/tests/cmdline/diff_tests.py(working copy)
> > @@ -5201,7 +5201,36 @@ def diff_summary_repo_wc_local_
> copy_unmodified(sbo
> > '--old=' + sbox.ospath('iota') + '@HEAD',
> > '--new=' + sbox.ospath('iota2'))
> >
> > +def diff_file_replaced_by_symlink(sbox):
>
> There should be an "@XFail()" decorator here, so `make test` (and
> `./diff_tests.py`) still exit 0 despite this test (X)FAILing.
>
> > + "diff base vs working: symlink replaces a file"
> > + sbox.build()
>
> Since this test doesn't commit, it can pass read_only=True, then build()
> would
> be cheaper.
>
> > + svntest.actions.run_and_verify_svn([
> > +'\ No newline at end of file\n',
>
> Please don't add new instances of backslash-space; it's an
> undefined/deprecated
> syntax that generates warnings in newer Pythons. See r1834787.
>
> Cheers,
>
> Daniel
>
RE: svn commit: r1834612 - in /subversion/branches/1.10.x-issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py
> -Original Message- > From: julianf...@apache.org [mailto:julianf...@apache.org] > Sent: donderdag 28 juni 2018 15:50 > To: comm...@subversion.apache.org > Subject: svn commit: r1834612 - in /subversion/branches/1.10.x- > issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py > > Author: julianfoad > Date: Thu Jun 28 13:50:28 2018 > New Revision: 1834612 > > URL: http://svn.apache.org/viewvc?rev=1834612=rev > Log: > On the '1.10.x-issue4758' branch: Fix SVN-4758 "Unable to shelve changes > when using custom diff-cmd". > > * subversion/libsvn_client/shelve.c > (shelf_write_patch): Ignore any config file while executing the diff, so > as to use the internal diff code. This resets quite a bit more configuration that might still be necessary. (WC-NG config is the first thing I would think of). I think you should duplicate the hash and explicitly remove a few keys. Bert
RE: shelf-tests failure on macOS
On the testsuite we explicitly disable the sleeps via the environment variable designed for this (except for a few specific tests). We compensate for this problem in quite a few places by making sure that we also change the number of characters in the file. Bert > -Original Message- > From: Julian Foad [mailto:julianf...@apache.org] > Sent: donderdag 14 juni 2018 19:35 > To: Philip Martin > Cc: dev@subversion.apache.org > Subject: Re: shelf-tests failure on macOS > > Philip Martin wrote on 2018-06-14: > > Philip Martin writes: > > > Julian Foad writes: > > >> The most unusual thing about these failing tests is the data they > > >> write. Strings of 5 or 6 low-value bytes, like: > > >> > > >> '\0\1\2\3\4\5' > > >> '\5\4\3\2\1\0' > > > > > > Those are the same size. Could it be a filesystem timestamp resolution > > > issue? The file changes but the timestamp does not and some change is > > > not detected? > > > > An HFS+ filesystem has a coarse 1s timestamp resolution so that would > > explain why the problem shows up there but not systems with subsecond > > resolution. > > Sounds like the correct explanation. > > > Neither shelve or unshelve appear to use svn_sleep_for_timestamp(). > > Actually shelve already does, in the relevant code path, which is inside > svn_client_shelf_unapply() where it uses svn_client_revert4() which does. > > Unshelve sleeps now, since r1833532. Hopefully that's the end of it. > > Thank you very much for the insight, Philip! > > - Julian
RE: Documentation to build SVN 1.10
> -Original Message- > From: Thomas Singer [mailto:thomas.sin...@syntevo.com] > Sent: vrijdag 20 april 2018 08:22 > To: dev@subversion.apache.org > Subject: Re: Documentation to build SVN 1.10 > > Thank you. It looks like this information has helped me to compile on > Linux, but on Windows gen-make.py is used and that does not like the > parameters --with-lz4=internal or --with-utf8proc=internal. As far as I know on Windows these libraries are always used as internal, so you don't have to add arguments for those. Bert
Re: New build requirements for 1.10?
I currently just use the internal builds for my binaries and don't see a reason to upgrade them separately. Utf8proc is only used in 'svn' at this time. I still build SQLite myself, but just passing the amalgamation works for others. I don't think there is even support to use external LZ4 and utf8proc on Windows yet. Bert On Tue, Mar 13, 2018 at 3:20 PM, Branko Čibej <br...@apache.org> wrote: > On 13.03.2018 14:27, Mark Phippard wrote: > > Starting to put together updated binaries for 1.10 release. Can > > someone summarize any new build requirements, particularly for Windows? > > > > I see the reference to LZ4. Should we use the "internal" > > implementation or are we expected to build and deliver a liblz4 for > > Windows? > > > > Anything else? I recall reading something about utf8proc but not sure > > what that is or what it is used for. FWIW, our 1.9 build process > > works for 1.10 but obviously if there are new, but optional, features > > or libraries added then we probably are not building them yet. > > We keep internal copies of both utf8proc and LZ4. I believe the default > Windows build uses these copies (svn --version --verbose will tell you). > > Only LZ4 is a new dependency, we've been using utf8proc for years. > > -- Brane > >
RE: Windows Compile Help
If you build ZLib with the Windows specific assembly optimizations you introduce known issues. Please make sure that you run the Subversion test that was designed to show you this problem. These assembly optimizations to zlib are a non-supported contributed package to zlib and not supported by the zlib authors. And as such they weren’t kept up to date over the last few releases. In some cases this may corrupt your data when transferred via ra-serf. This is how we found and reported the now-known problem to the zlib authors. They are currently not interested in fixing this issue, as the optimizations are non-supported and out of date anyway. Bert From: Troy Curtis Jr [mailto:troycurti...@gmail.com] Sent: zondag 28 januari 2018 16:23 To: Nathan Hartman <hartman.nat...@gmail.com> Cc: Subversion Development <dev@subversion.apache.org> Subject: Re: Windows Compile Help On Sun, Jan 28, 2018 at 12:21 AM Nathan Hartman <hartman.nat...@gmail.com <mailto:hartman.nat...@gmail.com> > wrote: On Jan 27, 2018, at 11:44 PM, Troy Curtis Jr <troycurti...@gmail.com <mailto:troycurti...@gmail.com> > wrote: I'm hoping someone can point me in the right direction with an issue I'm having compiling Subversion on Windows 10 using Visual Studio 2015 tools. I decided to break out of my comfort zone a bit and see if I could get the changes in for the py3c dependency added on the Windows side, but I am *not* a Windows dev. I've done a lot of learning, which as been fun, but I can't figure this last error out. I've attached the error log, and my WIP visual studio script that basically got me this far. It seems to complain the it can't find a handful of symbols related to zlib, but if I look at the static archive I see those names (though there are all those different calling conventions on windows, so maybe that is related to my issue?). Anyway, I've run out of ideas and was hoping for a little nudge. … Troy Forgive the second reply but on further study of the build log and some googling around, I think the absolute/relative paths are not the culprit, and that your suspicion about calling conventions may be correct. https://stackoverflow.com/questions/5424549/unresolved-externals-despite-linking-in-zlib-lib Which led to: http://www.zlib.net/DLL_FAQ.txt To summarize, CDECL is default and therefore probably what Subversion is building with, but zlib may be building with STDCALL. I would check if the zlib project defines ZLIB_WINAPI and if so, remove it and retry the build. Thanks so much for taking the time to look at this Nathan! You were right on. I had gotten close earlier but went the wrong way. At one point I *added* ZLIB_WINAPI to the config header, but of course it complained about a redefinition. It didn't click that I needed to *remove* it. Pulling that out of the build configuration finally got me linking (well, after added /safeseh to the asm build in zlib as well). Now to add swig to the mix and maybe eventually actually adding the change I want to test! XD Thanks again! Troy
RE: svn_dirent_t.size API inconsistency
> -Original Message-
> From: Stefan Fuhrmann [mailto:stef...@apache.org]
> Sent: donderdag 21 december 2017 16:01
> To: dev@subversion.apache.org
> Subject: Re: svn_dirent_t.size API inconsistency
>
> On 21.12.2017 15:14, Stefan Fuhrmann wrote:
> > I think I found an API documentation bug.
> > svn_types.h specifies for svn_dirent_t.size:
> >
> > /** length of file text, or 0 for directories */
> > svn_filesize_t size;
> >
> > However, (almost?) all implementations set it to
> > SVN_INVALID_FILESIZE for directories. This is also
> > what we do for svn_io_dirent_t.size.
> >
> > I discovered this as r1818578 broke our Perl tests.
> > The same test makes it clear that no API user could
> > have successfully used the API as documented.
> >
> > Therefore, I suggest to change the API doc to match
> > the implementation, check the code for consistency
> > and add an entry to our errata list.
+1 on the change.
Given that we already have all existing callers do the right thing (so no
behavior change), I'm not sure if adding something to our errata list is
necessary... But I don't see a problem with adding it anyway.
Bert
> >
> > -- Stefan^2.
> >
> Below the necessary patch w/o erratum.
>
> -- Stefan^2.
>
> [[[
> Fix inconsistent handling of svn_dirent_t.size for directories.
>
> Most code uses SVN_INVALID_FILESIZE for them, so change the docs to
> match
> that fact and update all users to consistently follow the new docstring.
>
> * subversion/include/svn_types.h
>(svn_dirent_t): Change documentation for SIZE.
>
> * subversion/libsvn_ra_local/ra_plugin.c
>(svn_ra_local__get_dir): Return the new default for directories.
>
> * subversion/libsvn_ra_serf/list.c
>(item_closed): Be sure to default to SVN_INVALID_FILESIZE.
>
> * subversion/libsvn_repos/list.c
>(fill_dirent): Set SIZE consistently with other RA layers.
>
> --This line, and those below, will be ignored--
>
> Index: subversion/include/svn_types.h
> ===
>
> --- subversion/include/svn_types.h(revision 1818804)
> +++ subversion/include/svn_types.h(working copy)
> @@ -652,7 +652,7 @@ typedef struct svn_dirent_t
> /** node kind */
> svn_node_kind_t kind;
>
> - /** length of file text, or 0 for directories */
> + /** length of file text, otherwise SVN_INVALID_FILESIZE */
> svn_filesize_t size;
>
> /** does the node have props? */
> Index: subversion/libsvn_ra_local/ra_plugin.c
> ===
>
> --- subversion/libsvn_ra_local/ra_plugin.c(revision 1818804)
> +++ subversion/libsvn_ra_local/ra_plugin.c(working copy)
> @@ -1387,7 +1387,7 @@ svn_ra_local__get_dir(svn_ra_session_t *
> {
> /* size */
> if (fs_entry->kind == svn_node_dir)
> -entry->size = 0;
> +entry->size = SVN_INVALID_FILESIZE;
> else
> SVN_ERR(svn_fs_file_length(&(entry->size), root,
> fullpath, iterpool));
> Index: subversion/libsvn_ra_serf/list.c
> ===
>
> --- subversion/libsvn_ra_serf/list.c(revision 1818932)
> +++ subversion/libsvn_ra_serf/list.c(working copy)
> @@ -139,6 +139,8 @@ item_closed(svn_ra_serf__xml_estate_t *x
>
> if (size)
> SVN_ERR(svn_cstring_atoi64(, size));
> + else
> +dirent.size = SVN_INVALID_FILESIZE;
>
> if (crev)
> SVN_ERR(svn_revnum_parse(_rev, crev, NULL));
> Index: subversion/libsvn_repos/list.c
> ===
>
> --- subversion/libsvn_repos/list.c(revision 1818804)
> +++ subversion/libsvn_repos/list.c(working copy)
> @@ -51,7 +51,7 @@ fill_dirent(svn_dirent_t *dirent,
> if (dirent->kind == svn_node_file)
> SVN_ERR(svn_fs_file_length(&(dirent->size), root, path,
> scratch_pool));
> else
> -dirent->size = 0;
> +dirent->size = SVN_INVALID_FILESIZE;
>
> SVN_ERR(svn_fs_node_has_props(>has_props, root, path,
> scratch_pool));
> ]]]
>
RE: [PATCH] Use the `WITHOUT ROWID` SQLite optimization for rep-cache.db
> -Original Message-
> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
> Sent: donderdag 30 november 2017 17:45
> To: dev@subversion.apache.org
> Subject: [PATCH] Use the `WITHOUT ROWID` SQLite optimization for rep-
> cache.db
>
> Hi all,
>
> The recent SQLite versions (starting from 3.8.2, released in December 2013)
> feature a `WITHOUT ROWID` optimization [1] that can be enabled when
> creating
> a table. In short, it works well for tables that have non-integer primary
> keys, such as
>
> name TEXT PRIMARY KEY
>
> by not maintaining the hidden rowid values and an another B-Tree to match
> between a primary key value and its rowid. This reduces the on-disk size
> and makes the lookups faster (a key → rowid → data lookup is replaced with
> a key → data lookup).
It doesn't add another B-tree for the primary key and its rowids. For the
primary key the main table is used as the index.
The case where things differ is when there are multiple indexes. In this case
normal table will always refer to the primary key using the rowed, while for
'WITHOUT ROWID' there will be referred to the primary key, which in general is
larger.
It really depends on the use case where this helps... or makes things worse...
Certain optimizations inside SQLite are not available for such tables.
For this specific table I think this helps as we only use the primary key
index, but I'm guessing it won't help us much on other tables.
When we bump the required SQLite version for the client we might want to update
the scheme of wc.db to use a sparse index for the move info table. This index
contains mostly NULL values, which SQLite can easily stop maintaining,
improving write("UPDATE") speed on the NODES tables considerably.
Bert
>
> Currently, the rep-cache.db schema uses a non-integer primary key:
>
> hash TEXT NOT NULL PRIMARY KEY
>
> and can benefit from this optimization. A quick experiment showed a
> reduction of the on-disk size of the database by ~1.75x. The lookups
> should also be faster, both due to the reduced database size and due to
> the lesser amount of internal bsearches. This should improve the times
> of new commits and `svnadmin load`, especially for large repositories
> that also have large rep-cache.db files.
>
> I think that it would be nice to have this optimization in rep-cache.db,
> and that we can start using it in a compatible way:
>
> - All existing rep-cache.db statements are compatible with it.
>
> - Since SQLite versions prior to 3.8.2 don't support it, we would
> only create the new tables with this optimization in fsfs format 8,
> and simultaneously bump the minimal required SQLite version from
> 3.7.12 (May 2012) to 3.8.2 (December 2013). This would ensure that
> all binaries supporting format 8 can work with the tables with this
> optimization.
>
> Would there be any objections to a change like this (see the attached
> patch)?
>
> [1] https://sqlite.org/withoutrowid.html
>
>
> Thanks,
> Evgeny Kotkov
[PATCH] Hackathon project: Dumping viewspec
Hi, At the Aachen hackathon I promised to write some code to spit out the sparse definition of a working copy, or in other words some initial dumb viewspec output. Testing this on a test working copy with [[ $ svn switch --list \SharpSvn\trunk ]] I can now see output like [[ svn checkout https://ctf.open.collab.net/svn/repos/sharpsvn/trunk@4003 /SharpSvn/trunk svn update -r 4004 /SharpSvn/trunk/imports/patches/openssl/201603-capi-sha-openssl-1.0.2.patch svn switch ^/branches/1.800x/contrib@4004 /SharpSvn/trunk/contrib svn update -r 0 /SharpSvn/trunk/LICENSE.txt svn update -r 4004 /SharpSvn/trunk/src/SharpPlink --set-depth files svn update -r 4004 /SharpSvn/trunk/src/SharpSvn --set-depth files svn update --set-depth files /SharpSvn/trunk/src/SharpSvn/Commands svn update --set-depth exclude /SharpSvn/trunk/build.info ]] So this new command spits out the shell commands necessary to create a new working copy with exactly the same layout and revisions as the existing working copy. This could be the starting point for an improved format, or for creating scripts that transform this in something more useful, e.g. by filtering out unnecessary details. I put the current code in a patch file attached to this message to allow discussing this feature before putting it on trunk. Bert viewspec-dump.patch Description: Binary data
RE: svn commit: r1815799 - in /subversion/trunk/subversion: libsvn_ra_serf/commit.c tests/libsvn_ra/ra-test.c
> -Original Message-
> From: kot...@apache.org [mailto:kot...@apache.org]
> Sent: maandag 20 november 2017 13:44
> To: comm...@subversion.apache.org
> Subject: svn commit: r1815799 - in /subversion/trunk/subversion:
> libsvn_ra_serf/commit.c tests/libsvn_ra/ra-test.c
>
> Author: kotkov
> Date: Mon Nov 20 12:43:33 2017
> New Revision: 1815799
>
> URL: http://svn.apache.org/viewvc?rev=1815799=rev
> Log:
> ra_serf: Properly process lock tokens for empty relative paths ("")
> within the commit editor.
I'm not sure if we should really allow this.
The delta editor explicitly describes that you are opening a directory and then
edit the nodes inside. Only changing properties on the root is allowed and
other operations are all on nodes within. Allowing to open the node itself
again may cause all kinds of problems as there are now multiple handles
pointing to the same thing. How will this be expressed in the
filesystem/transaction?
I'm surprised that all the other filesystems allow this, so perhaps this is a
safe change... but the documentation in svn_delta.h doesn't describe this as a
safe extension. (Which would theoretically allow this as a safe extension in
later versions... but we must make sure that we are not opening new issues this
way)
Currently I would guess that making the ra layers provide a proper error for
this case would not be a bad thing... All our drivers explicitly open an
existing directory when they want to edit a file...
Bert
RE: [RFC] svn commit --parents option needed
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: vrijdag 17 november 2017 14:26 > To: Sam White <sam94wh...@gmail.com> > Cc: dev@subversion.apache.org > Subject: Re: [RFC] svn commit --parents option needed > > On Tue, Nov 14, 2017 at 03:57:45PM +, Sam White wrote: > > Hi Developers, > > > > I propose the addition of an equivalent to the --parents option to "svn > > commit", to check in the directory structure as well as any files > > specified. > > > > I understand that with svn add, the --parents option is available. However, > > the use case I have in mind is one that I come across quite often, > > involving changelists and SVN moves. > > > > If I add files to changelist, I expect to be able to commit any changes to > > them quickly and easily - that's the point, right? But if I perform an SVN > > move on these items, to a directory which is not yet committed, because I > > cannot yet add directories to the changelist, when I go to commit the > > files, I get the error > > > > svn: E29: '/some/new/directory/here' is not known to exist in the > > repository and is not part of the commit, yet its child > > '/some/new/directory/here/file_on_changelist.txt' is part of the commit > > > > If I then try and commit those files, as sort of a "pre-commit" commit, > > then i get the error > > > > Cannot commit '/some/directory/here' because it was moved from > > '/other/directory/here/' which is not part of the commit; both sides of the > > move must be committed together > > > > The workaround for this seems to involve a mess of committing these > > directories together, with the option --depth=empty, and then committing > > with the changelist. Alternatively, I could just skip the --depth=empty, > > and let the commit handle the fiels as well - but then, what was the point > > in making a changelist? I still end up formulating some long command! > > > > I was asking about this in the #svn IRC - here is the chat log: > > http://colabti.org/irclogger/irclogger_log/svn?date=2017-11-14#l21 > > > > Is what I am suggesting clear? I'd appreciate your thoughts. > > > > Thanks, > > > > Sam (sixquidsquid) > > So to reiterate: > > I move a directory which contains some files which belong to a > changelist and some which do not belong to this changelist. > > I now want to use commit --cl in order to commit the modifications in > the files listed in my changelist. Because some or all of these files > sit inside the moved directory I have to commit this move as well. > > In the repository, the moved directory will be both copied to > the new location and deleted at its old path in this same commit. > > And a server-side directory copy is always recursive; there is no > way to exclude any children from the copy unless we're explicitly > marking them deleted in the copy target. > So some files which are not part of my changelist will be moved along. > > Is your goal to *only move the files* which are part of your changelist? > I believe this could not be made to work without lots of headache. > > Or is your goal to perform the directory move recursively, and in the > same revision commit modifications to only those files which are part > of the changelist? I believe this can be made to work. > > I'll note that the current behaviour in the case where a changelist > contains a file which has been moved directly, rather than having > been moved along with a parent directory, supports your feature > request because this case already "just works": > > $ svn cl my-file alpha > A [my-file] alpha > $ echo foo >> alpha > $ svn mv alpha alpha2 > A alpha2 > D alpha > $ svn st > > --- Changelist 'my-file': > D alpha > > moved to alpha2 > A +alpha2 > > moved from alpha > $ svn ci alpha2 > $ svn ci --cl my-file -m "edit and move alpha" > Deleting alpha > Adding alpha2 > Transmitting file data .done > Committing transaction... > Committed revision 3. How would this be affected by property changes on parent directories? Should these be committed or not when using --parents. Especially around changes to svn:mergeinfo this could be pretty interesting as it would make it much easier to commit only some parts of a merge without warning. Bert
RE: svn commit: r1811786 - /subversion/trunk/subversion/bindings/swig/include/svn_types.swg
> -Original Message- > From: james...@apache.org [mailto:james...@apache.org] > Sent: woensdag 11 oktober 2017 05:08 > To: comm...@subversion.apache.org > Subject: svn commit: r1811786 - > /subversion/trunk/subversion/bindings/swig/include/svn_types.swg > > Author: jamessan > Date: Wed Oct 11 03:08:19 2017 > New Revision: 1811786 > > URL: http://svn.apache.org/viewvc?rev=1811786=rev > Log: > * subversion/bindings/swig/include/svn_types.swg: > (unsigned char digest typemap): When svn_md5_digest_to_cstring() > returns NULL, > pass an empty string to rb_str_new2(). This problem is so common we even have a special svn_md5_digest_to_cstring_display() function for this case that explicitly avoids returning NULL. You might want to switch to that version to document the requested behavior. (Found via the branch update from brane) Bert
RE: Merkle trees in svn [was: Quick question about the sha1-checksum for directories in svn.]
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: donderdag 5 oktober 2017 19:29 > To: dev@subversion.apache.org > Subject: Re: Merkle trees in svn [was: Quick question about the sha1- > checksum for directories in svn.] > > On 05.10.2017 19:12, Daniel Shahaf wrote: > > Branko Čibej wrote on Thu, 05 Oct 2017 18:44 +0200: > >> On 05.10.2017 16:46, Julian Foad wrote: > >>> Calculation of a directory's hash would have to happen for each > >>> directory where the user has mixed access to the immediate children, > >>> and for all parents of such a directory up to the root. > >> And /that/ is the painful part: the fact that you need a depth-first > >> traversal of the tree in order to calculate the hash for the root > >> directory. And the reason why we're not exposing the directory hash, > >> even if the FS stores it. > > What if we only returned a checksum for nodes to which the user had > > full recursive access? E.g., with "[/A/B] *=", the caller would be > > able to retrieve checksums for /A/C, /A/D, /A/mu, and /A's property > > hash, and for descendants of the first two, but that's it. > > That would leak permission settings. A user would know that she only sees a > partial directory merely by checking for the presence of the directory > checksum. We already explicitly leak that there are server excluded subtrees in/for our delta editor / reporter design, so this would not be a security regression. Bert > > -- Brane
RE: Workflow for editing the subversion website
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 4 oktober 2017 02:05 > To: dev@subversion.apache.org > Subject: Re: Workflow for editing the subversion website > > Johan Corveleyn wrote on Tue, 03 Oct 2017 23:32 +0200: > > The recent work on our quick-start.html page by Pavel Lyalyakin > > prompted some thinking about how to better organize our site editing. > > Pavel asked about lightweight branching and Daniel suggested to copy > > site/publish to site/staging and having it served as > > http://subversion.staging.apache.org/ to facilitate previewing [1]. > > > > Small technical note: *.staging.apache.org is what the CMS uses, also it will > cause SSL errors since the *.apache.org certificate won't match that > hostname. (Compare svn-eu.apache.org/svn.eu.apache.org: asterisk in the > cert doesn't match dot in the URL's hostname) We can get around both > problems by having the staging preview site live on, say, https://subversion- > staging.apache.org/ (or even on svn-qavm). > > > Small changes and corrections can go directly to the live site. Maybe > > we'll need some exceptions for things like news, release notes and > > security pages, which are usually updated as part of releases and get > > a lot of eyes already. > > > > Thoughts? > > I'd like to understand the topology / flow of changes: what ensures that > changes made directly to publish are not reverted by a subsequent > promotion of staging? > > FWIW, in the Apache CMS, a "publish" operation uses 'svnmucc rm publish > cp N staging publish', so it's an O(1) operation, but it literally overwrites > any > changes that may have been made directly to publish/. (I'm glossing over a > detail but that's the gist) I think we should just use svn merge, to avoid these problems? No CMS here. Bert > > Cheers, > > Daniel
Repository load failing on 1.9.x
Hi Stefan, I'm still seeing failures when loading repositories on 1.9.x since the SHA1 collision handling changes and currently no nominations in STATUS that will change the behavior back to something that will work. One of the repositories I see this problem with is the original test schema repository around merging that Mark Phippard created when we introduced Subversion 1.5, so it won't be hard to share a testcase. (https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/src/SharpSvn.TestBuild er/Resources/MergeScenario.repos, 36 kbyte, username guest, no password) Are you still interested in working on a fix for this scenario? Bert
RE: svn commit: r1803143 - in /subversion/trunk/subversion: include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: woensdag 30 augustus 2017 07:07
> To: kot...@apache.org
> Cc: dev@subversion.apache.org; comm...@subversion.apache.org
> Subject: Re: svn commit: r1803143 - in /subversion/trunk/subversion:
> include/ libsvn_delta/ libsvn_ra_serf/ mod_dav_svn/
>
> Good morning Evgeny,
>
> kot...@apache.org wrote on Thu, 27 Jul 2017 09:00 +:
> > +++ subversion/trunk/subversion/include/svn_delta.h Thu Jul 27 09:00:43
> 2017
> > @@ -678,6 +690,9 @@ svn_txdelta_skip_svndiff_window(apr_file
> > * @{
> > */
> >
> > +/* Forward declarations. */
> > +typedef struct svn_delta_editor_t svn_delta_editor_t;
> > +
> > /** A structure full of callback functions the delta source will invoke
> > * as it produces the delta.
> > *
> > @@ -859,7 +874,7 @@ svn_txdelta_skip_svndiff_window(apr_file
> > * dead; the only further operation which may be called on the editor
> > * is @c abort_edit.
> > */
> > -typedef struct svn_delta_editor_t
> > +struct svn_delta_editor_t
> > {
> >/** Set the target revision for this edit to @a target_revision. This
> > * call, if used, should precede all other editor calls.
> > @@ -1131,9 +1146,38 @@ typedef struct svn_delta_editor_t
> >svn_error_t *(*abort_edit)(void *edit_baton,
> > apr_pool_t *scratch_pool);
> >
> > + /** Apply a text delta stream, yielding the new revision of a file.
> > + *
> > + * @a file_baton indicates the file we're creating or updating, and the
> > + * ancestor file on which it is based; it is the baton set by some
> > + * prior @c add_file or @c open_file callback.
> > + *
> > + * @a open_func is a function that opens a #svn_txdelta_stream_t
> object.
> > + * @a open_baton is provided by the caller.
> > + *
> > + * @a base_checksum is the hex MD5 digest for the base text against
> > + * which the delta is being applied; it is ignored if NULL, and may
> > + * be ignored even if not NULL. If it is not ignored, it must match
>
> What's the rationale for allowing drivees to ignore the checksum?
>
> This leeway enables failure modes that wouldn't be possible without it.
> (Drivers that are aware of this leeway will validate checksums even if the
> drivee doesn't, leading to duplicate work; drivers that are unaware of this
> requirement might not get checksum errors they should have.)
>
> I get that you just copied this part of the docstring from apply_textdelta(),
> but I'd like to understand what's the rationale here. (And to see if this
> leeway should be deprecated)
I think this just documents current behavior. Yes a 1.9+ client against a 1.9+
server will always have a checksum, but this is not the case when mixing older
clients and servers.
Original serf versions (form before we declared this stable) typically never
provided the checksum. And in some cases bulk requests didn't have all the
checksums either. I remember fixing a few cases around WC-NG to make sure all
ra layers reported the same errors in some exceptional cases.
Bert
RE: svn commit: r1806552 - /subversion/branches/shelve/subversion/svn/svn.c
> -Original Message-
> From: julianf...@apache.org [mailto:julianf...@apache.org]
> Sent: dinsdag 29 augustus 2017 12:25
> To: comm...@subversion.apache.org
> Subject: svn commit: r1806552 -
> /subversion/branches/shelve/subversion/svn/svn.c
>
> Author: julianfoad
> Date: Tue Aug 29 10:25:21 2017
> New Revision: 1806552
>
> URL: http://svn.apache.org/viewvc?rev=1806552=rev
> Log:
> On the 'shelve' branch: Expand & clarify help text; state limitations.
>
> * subversion/svn/svn.c
> (svn_cl__cmd_table): Tweak help text for shelve commands.
>
> Modified:
> subversion/branches/shelve/subversion/svn/svn.c
>
> Modified: subversion/branches/shelve/subversion/svn/svn.c
> URL:
> http://svn.apache.org/viewvc/subversion/branches/shelve/subversion/svn/
> svn.c?rev=1806552=1806551=1806552=diff
> ==
>
> --- subversion/branches/shelve/subversion/svn/svn.c (original)
> +++ subversion/branches/shelve/subversion/svn/svn.c Tue Aug 29 10:25:21
> 2017
> @@ -1650,23 +1650,31 @@ const svn_opt_subcommand_desc2_t svn_cl_
> {opt_targets, 'R', opt_depth, 'q', opt_changelist} },
>
>{ "shelve", svn_cl__shelve, {0}, N_
> -("Shelve changes.\n"
> +("Put a local change aside, as if putting it on a shelf.\n"
> "usage: 1. shelve [--keep-local] NAME PATH...\n"
> " 2. shelve --delete NAME\n"
> " 3. shelve --list\n"
> "\n"
> - " 1. Save the local changes in the given PATHs to a patch file, and\n"
> - " revert those changes from the WC unless '--keep-local' is
> given.\n"
> + " 1. Save the local change in the given PATHs to a patch file, and\n"
> + " revert that change from the WC unless '--keep-local' is given.\n"
> " If a log message is given with '-m' or '-F', include it at the\n"
> " beginning of the patch file.\n"
> "\n"
> - " 2. Delete the shelved patch NAME.\n"
> + " 2. Delete the shelved change NAME.\n"
> "\n"
> - " 3. List shelved patches. Include the first line of any log message\n"
> - " and some details about the contents of the patch, unless '-q'
> is\n"
> + " 3. List shelved changes. Include the first line of any log message\n"
> + " and some details about the contents of the change, unless '-q'
> is\n"
> " given.\n"
> "\n"
> - " Patch files are named .svn/shelves/NAME.patch\n"),
> + " The kinds of change you can shelve are those supported by 'svn
> diff'\n"
> + " and 'svn patch'. The following are currently NOT supported:\n"
> + " mergeinfo changes, copies, moves, mkdir, rmdir,\n"
> + " 'binary' content, uncommittable states\n"
svn patch supports binary content. The limitation here is probably that
currently only 'svn diff --git' produces the patches in the proper form, while
other invocations skip binary files.
Bert
RE: svn commit: r1806548 - in /subversion/trunk/subversion: svn/svn.c svnbench/svnbench.c tests/cmdline/basic_tests.py
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: dinsdag 29 augustus 2017 11:57 > To: comm...@subversion.apache.org > Subject: svn commit: r1806548 - in /subversion/trunk/subversion: svn/svn.c > svnbench/svnbench.c tests/cmdline/basic_tests.py > > Author: stefan2 > Date: Tue Aug 29 09:56:31 2017 > New Revision: 1806548 > > URL: http://svn.apache.org/viewvc?rev=1806548=rev > Log: > As Julian discovered, '--search' as used with 'svn log' is may not suitable > for 'svn ls'. File name matching should be case-sensitive and requires > full patterns just like e.g. the ordinary unix command line 'ls' command. > > Therefore, introduce a separate '--pattern' option for 'svn log' that works > similar to patterns with Unix command line 'ls'. Since the actual matching > already confirms to that, we only need a different option pre-processing. Perhaps we could use --glob, to allow other syntax patterns later? Not sure... perhaps --glob is too technical. Bert
RE: [PATCH] Add XFail test for relocating working copy with removed externals
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: maandag 28 augustus 2017 15:26
> To: dev@subversion.apache.org
> Subject: [PATCH] Add XFail test for relocating working copy with removed
> externals
>
> Log message:
> [[[
> Add XFail test for relocating working copy with removed externals.
>
> Found by: TortoiseSVN dump
> Patch by: Ivan Zhakov {ivan {at} visualsvn.com}
>
> * subversion/tests/cmdline/relocate_tests.py
> (relocate_with_removed_externals): New test.
> (test_list): Add new test to the test list.
> ]]]
+1
Feel free to commit this.
I'll try to commit this later this week if you don't get to this. You can just
use your committer name in the Patch by line, to match things up in the
contribulyzer.
(Or just commit it if you feel like it;-))
Bert
RE: svn commit: r1806017 - /subversion/trunk/subversion/libsvn_ra_serf/merge.c
> -Original Message- > From: kot...@apache.org [mailto:kot...@apache.org] > Sent: donderdag 24 augustus 2017 11:43 > To: comm...@subversion.apache.org > Subject: svn commit: r1806017 - > /subversion/trunk/subversion/libsvn_ra_serf/merge.c > > Author: kotkov > Date: Thu Aug 24 09:43:28 2017 > New Revision: 1806017 > > URL: http://svn.apache.org/viewvc?rev=1806017=rev > Log: > ra_serf: Prevent the server from generating and sending the full MERGE > response in cases when we don't require it. > > The full response is not required when working over HTTPv2 protocol. > When working over HTTPv1, it's only required when the new working copy > properties need to be stored as part of a commit (indicated by a non-null > svn_ra_push_wc_prop_func_t callback). Nice catch! Does this affect performance enough that we should backport this fix? Bert
RE: Data corruption bug in WC, apparently due to race condition?
> -Original Message- > From: Philip Martin [mailto:phi...@codematters.co.uk] > Sent: donderdag 27 juli 2017 19:57 > To: Karl Fogel <kfo...@red-bean.com> > Cc: Subversion Dev <dev@subversion.apache.org> > Subject: Re: Data corruption bug in WC, apparently due to race condition? > > Karl Fogel <kfo...@red-bean.com> writes: > > > 1) Start an SVN commit. > > > > 2) While the commit is in progress, edit and save a > > change to one of the files that's being committed. > > > > 3) The commit completes successfully, or "successfully", but... > > > > ...now the repository has the file contents from before my edit of > > (2), the working copy has the file contents from *after* my edit of > > (2), but SVN reports no local modifications when I do 'svn status'. > > That's... bad, right? :-) > > The post-commit processing on the client side is not checking for > modifications before recording filesize/timestamp in the nodes table in > .svn/wc.db. There used to be a system for this around the release of Subversion 1.7.0. Not sure what happened to this... There should be a comparison (probably via one of the wc question apis) if the timestamp changed since what was committed. But even then there is a theoretical issue, between the file install and then obtaining the timestamp+size directly after that. But you shouldn't be able to trigger that without a debugger. Unlike this case where the whole commit is locked. We should do better, but we don't promise that this editing while committing is 100% stable. During the working copy lock we should have exclusive access to the locked parts of the working copy... Bert
RE: svn commit: r1803158 - in /subversion/trunk/subversion/libsvn_subr: compress.c compress_lz4.c compress_zlib.c encode.c
> -Original Message- > From: kot...@apache.org [mailto:kot...@apache.org] > Sent: donderdag 27 juli 2017 12:00 > To: comm...@subversion.apache.org > Subject: svn commit: r1803158 - in > /subversion/trunk/subversion/libsvn_subr: compress.c compress_lz4.c > compress_zlib.c encode.c > > Author: kotkov > Date: Thu Jul 27 09:59:47 2017 > New Revision: 1803158 > > URL: http://svn.apache.org/viewvc?rev=1803158=rev > Log: > Split libsvn_subr/compress.c into three files. > > This file contained routines for zlib and LZ4 compression and for general > data encoding, such as svn__encode_uint(). It would be better to maintain > all of these three groups separately. > > * subversion/libsvn_subr/compress.c > (svn__encode_uint, svn__encode_int, svn__decode_uint, > svn__decode_int): >Move to encode.c. > (svn_zlib__compiled_version, svn_zlib__runtime_version, >svnCompressBound, MIN_COMPRESS_SIZE, zlib_encode, zlib_decode, >svn__compress_zlib, svn__decompress_zlib): Move to compress_zlib.c. > (svn__compress_lz4, svn__decompress_lz4): Move to compress_lz4.c. > > * subversion/libsvn_subr/encode.c, > subversion/libsvn_subr/compress_zlib.c, > subversion/libsvn_subr/compress_lz4.c: New files. > > Added: > subversion/trunk/subversion/libsvn_subr/compress_lz4.c (with props) > subversion/trunk/subversion/libsvn_subr/compress_zlib.c (with props) > subversion/trunk/subversion/libsvn_subr/encode.c (with props) > Removed: > subversion/trunk/subversion/libsvn_subr/compress.c Would have been nice if all these files were based of a copy of compress.c, to allow following history in a bit easier way. Bert
RE: svn commit: r1801970 - in /subversion/branches/shelve-checkpoint/subversion: libsvn_client/shelve.c svn/shelve-cmd.c
> -Original Message-
> From: julianf...@apache.org [mailto:julianf...@apache.org]
> Sent: vrijdag 14 juli 2017 16:22
> To: comm...@subversion.apache.org
> Subject: svn commit: r1801970 - in /subversion/branches/shelve-
> checkpoint/subversion: libsvn_client/shelve.c svn/shelve-cmd.c
>
> Author: julianfoad
> Date: Fri Jul 14 14:21:35 2017
> New Revision: 1801970
>
> URL: http://svn.apache.org/viewvc?rev=1801970=rev
> Log:
> On the 'shelve-checkpoint' branch: make 'svn shelve --list' more verbose.
>
> Print the patch file age and size, and (unless '-q') also a diffstat.
>
> * subversion/libsvn_client/shelve.c
> (svn_client_shelves_list): Retrieve more stats including file size and
> mtime.
>
> * subversion/svn/shelve-cmd.c
> (shelves_list): Print each patch's age and size, and run 'diffstat' if
> found in the path.
> (svn_cl__shelves,
>svn_cl__shelves): Update callers.
>
> Modified:
> subversion/branches/shelve-checkpoint/subversion/libsvn_client/shelve.c
> subversion/branches/shelve-checkpoint/subversion/svn/shelve-cmd.c
>
> Modified: subversion/branches/shelve-
> checkpoint/subversion/libsvn_client/shelve.c
> URL: http://svn.apache.org/viewvc/subversion/branches/shelve-
> checkpoint/subversion/libsvn_client/shelve.c?rev=1801970=1801969
> =1801970=diff
> ==
>
> --- subversion/branches/shelve-
> checkpoint/subversion/libsvn_client/shelve.c (original)
> +++ subversion/branches/shelve-
> checkpoint/subversion/libsvn_client/shelve.c Fri Jul 14 14:21:35 2017
> @@ -314,7 +314,7 @@ svn_client_shelves_list(apr_hash_t **dir
>
>SVN_ERR(svn_wc__get_shelves_dir(_dir, ctx->wc_ctx,
> local_abspath,
>scratch_pool, scratch_pool));
> - SVN_ERR(svn_io_get_dirents3(dirents, shelves_dir, TRUE
> /*only_check_type*/,
> + SVN_ERR(svn_io_get_dirents3(dirents, shelves_dir, FALSE
> /*only_check_type*/,
>result_pool, scratch_pool));
>
>/* Remove non-shelves */
>
> Modified: subversion/branches/shelve-checkpoint/subversion/svn/shelve-
> cmd.c
> URL: http://svn.apache.org/viewvc/subversion/branches/shelve-
> checkpoint/subversion/svn/shelve-
> cmd.c?rev=1801970=1801969=1801970=diff
> ==
>
> --- subversion/branches/shelve-checkpoint/subversion/svn/shelve-cmd.c
> (original)
> +++ subversion/branches/shelve-checkpoint/subversion/svn/shelve-cmd.c
> Fri Jul 14 14:21:35 2017
> @@ -51,21 +51,36 @@ get_shelf_name(const char **shelf_name,
> /* Display a list of shelves */
> static svn_error_t *
> shelves_list(const char *local_abspath,
> + svn_boolean_t diffstat,
> svn_client_ctx_t *ctx,
> - apr_pool_t *pool)
> + apr_pool_t *scratch_pool)
> {
>apr_hash_t *dirents;
>apr_hash_index_t *hi;
>
> - SVN_ERR(svn_client_shelves_list(, local_abspath, ctx, pool, pool));
> + SVN_ERR(svn_client_shelves_list(, local_abspath,
> + ctx, scratch_pool, scratch_pool));
>
> - for (hi = apr_hash_first(pool, dirents); hi; hi = apr_hash_next(hi))
> + for (hi = apr_hash_first(scratch_pool, dirents); hi; hi =
> apr_hash_next(hi))
> {
I know it is just a prototype, but some stable sorting would be nice.
>const char *name = apr_hash_this_key(hi);
> + svn_io_dirent2_t *dirent = apr_hash_this_val(hi);
> + int age = (apr_time_now() - dirent->mtime) / 100 / 60;
>
> - if (strstr(name, ".patch"))
> + if (! strstr(name, ".patch"))
> +continue;
> +
> + printf("%-30s %6d mins old %10ld bytes\n",
> + name, age, (long)dirent->filesize);
And in general we try to avoid the standard print functions as these might not
be as compatible as expected. (UTF-8 support, buffering, etc.)
> +
> + if (diffstat)
> {
> - printf("%s\n", name);
> + char *path = svn_path_join_many(scratch_pool,
> + local_abspath, ".svn/shelves",
> name,
> + SVN_VA_NULL);
> +
> + system(apr_psprintf(scratch_pool, "diffstat %s 2> /dev/null",
> path));
> + printf("\n");
And this will certainly fail on Windows (but the error is ignored anyway). I
would recommend flushing stdout before calling system() on other platforms.
Bert
> }
> }
>
> @@ -94,7 +109,9 @@ svn_cl__shelve(apr_getopt_t *os,
>i
RE: svn commit: r1801946 - in /subversion/trunk/subversion/libsvn_subr/lz4: LICENSE lz4.c lz4.h
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: vrijdag 14 juli 2017 14:41 > To: Branko Čibej <br...@apache.org> > Cc: comm...@subversion.apache.org > Subject: Re: svn commit: r1801946 - in > /subversion/trunk/subversion/libsvn_subr/lz4: LICENSE lz4.c lz4.h > > Branko Čibej <br...@apache.org> writes: > > > Hmmm. Evgeny, don't you use a client that understands the svn:auto- > props > > inherited property? On trunk: > > > > $ svn pg svn:auto-props . > > *.c = svn:eol-style=native > > *.cpp = svn:eol-style=native > > *.h = svn:eol-style=native > > *.hpp = svn:eol-style=native > > *.java = svn:eol-style=native > > ... > > > > > > At least your .c and .h files should've been added with correct > > eol-style ... > > Apparently, the /upstream doesn't have svn:auto-props, so the files I > have added there don't have svn:eol-style. And so, no properties were > set after I copied them. The autoprops are on ^/subversion/trunk and are (or should be) *inherited*. Which client did you use for adding? Bert > > > Regards, > Evgeny Kotkov
RE: [RFC] Shelving and Checkpointing
> -Original Message- > From: Julian Foad [mailto:julianf...@apache.org] > Sent: woensdag 12 juli 2017 16:38 > To: Mark Phippard <markp...@gmail.com> > Cc: Subversion Developers <dev@subversion.apache.org> > Subject: Re: [RFC] Shelving and Checkpointing > > Mark Phippard wrote: > > Nice to see you have gotten this far. > > > > I am not even sure how this behaves with git stash but what happens if > > the patch cannot be applied cleanly? Is the path to "fixing things" > > relatively clear? Like does patch just create conflicts that you > > resolve like anything else? > > It is 'svn patch' -- so it raises conflicts. Svn patch creates reject files. It doesn't create conflicts (yet). Bert
RE: [PATCH] Tweak the SHA-1 FAQ entry
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: vrijdag 7 juli 2017 16:46 > To: Subversion Development <dev@subversion.apache.org> > Subject: [PATCH] Tweak the SHA-1 FAQ entry > > Hi all, > > I made an attempt to tweak the SHA-1 FAQ entry (which is available at > https://subversion.apache.org/faq#shattered-sha1) to make it a bit more > user-friendly. > > Please see the attached patch. What do you think about making a change > like this? > > For convenience, here is the final result as plain text: > > [[[ > How is Subversion affected by SHA-1 hash collisions? > > Publication of the first known SHA-1 collision by Google and CWI unveiled a > couple of related issues in the Subversion's use of SHA-1. The Subversion's > core does not rely on SHA-1 for content indexing, but it was being used for > such purposes in the following supplementary features: > > - repository data deduplication feature, and > - content deduplication feature in the working copy. > > Speaking of the repository data deduplication feature, this can result in > inability to access files with colliding SHA-1 values or cause data loss for > such files. To prevent different content with identical SHA-1 from being > stored in a repository, upgrade to 1.9.6 or 1.8.18 which, by default, > prevent storing data with such collisions. See our SHA-1 advisory for > details. > > Until the upgrade to these new releases is available, Unix-based servers can > use the pre-commit hook found here. As an aside, we welcome Windows > developers > to submit a pre-commit script for the Windows platform. More information > on > submission can be found here. > > The working copy uses SHA-1 for deduplication of the stored content, and for > performance reasons a client will avoid fetching content with the same SHA-1 > checksum. The workaround for this issue is to prevent storage of the colliding > objects in the first place, via upgrade to 1.9.6 or installation of the > aforementioned pre-commit script. > > Storing content with SHA-1 collisions it not a supported use case. If you Except for s/ it / is / on this line, +1... Looks very good! Thanks, Bert > have content with colliding SHA-1 hash values, we suggest you transform it > via gzip before committing it to avoid the collision altogether. Moreover, > an upgrade to 1.9.6 to prevent future insertion of duplicates is highly > recommended. > ]]] > > > Regards, > Evgeny Kotkov
RE: svn commit: r1801108 - in /subversion/trunk/subversion/bindings/javahl/native: Array.cpp CreateJ.cpp Iterator.cpp OperationContext.cpp RemoteSession.cpp RevisionRangeList.cpp
> -Original Message- > From: phi...@apache.org [mailto:phi...@apache.org] > Sent: donderdag 6 juli 2017 22:56 > To: comm...@subversion.apache.org > Subject: svn commit: r1801108 - in > /subversion/trunk/subversion/bindings/javahl/native: Array.cpp CreateJ.cpp > Iterator.cpp OperationContext.cpp RemoteSession.cpp > RevisionRangeList.cpp > > Author: philip > Date: Thu Jul 6 20:56:14 2017 > New Revision: 1801108 > > URL: http://svn.apache.org/viewvc?rev=1801108=rev > Log: > Add exception checks to some of the JavaHL native code to avoid JVM > warnings about JNI problems of the form: > > WARNING in native method: JNI call made without checking exceptions > when required to > > * subversion/bindings/javahl/native/Array.cpp > (Array::init): Add exception check. > > * subversion/bindings/javahl/native/CreateJ.cpp > (CreateJ::Mergeinfo): Add exception check. > > * subversion/bindings/javahl/native/Iterator.cpp > (init_iterator, Iterator::next): Add exception check. > > * subversion/bindings/javahl/native/OperationContext.cpp > (OperationContext::closeTunnel): Add exception check. > > * subversion/bindings/javahl/native/RemoteSession.cpp > (build_string_array, long_iterable_to_revnum_array, >location_hash_to_map): Add exception check. > > * subversion/bindings/javahl/native/RevisionRangeList.cpp > (RevisionRangeList::RevisionRangeList): Add exception check. Should we backport these to 1.9.x? Bert
RE: 1.8.18 release available for testing/signing
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: maandag 3 juli 2017 12:56 > To: dev@subversion.apache.org > Subject: 1.8.18 release available for testing/signing > > The 1.8.18 release can now be tested and signed. > Get it from https://dist.apache.org/repos/dist/dev/subversion > as usual, and add your signatures there. Thanks! +1 for release Visual Studio 2015 on Windows 8.1 VM (x86 build on x64 system) apr 1.6.2 apr-util 1.6.0 apr_memcache 1.6.0 bdb 4.4.20 expat 2.2.0 httpd 2.4.25 mod_dav 2.4.25 openssl 1.0.2l sasl 2.1.26 serf 1.3.9 sqlite 3.19.3 zlib 1.2.11 Ran the [fsfs] x [local | svn | serf] tests + [bdb] x [local] + JavaHL, verified files with tag, etc. Bert
RE: 1.9.6 up for signing/testing
> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: vrijdag 30 juni 2017 15:06 > To: dev@subversion.apache.org > Subject: 1.9.6 up for signing/testing > > The 1.9.6 release artifacts are now available for testing/signing. > > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > I'm aiming to release this within a week. (CHANGES points to this > Wednesday, which may be a bit optimistic on my part.) +1 for release Visual Studio 2015 on Windows 8.1 VM (x86 build on x64 system) apr 1.6.2 apr-util 1.6.0 apr_memcache 1.6.0 bdb 4.4.20 expat 2.2.0 httpd 2.4.25 mod_dav 2.4.25 openssl 1.0.2l sasl 2.1.26 serf 1.3.9 sqlite 3.19.3 zlib 1.2.11 Ran the [fsfs | bdb] x [local | svn | serf] tests + JavaHL, verified files with tag, etc. Bert
RE: stricter text conflicts in 1.10
Feel free to revert my patch until we find a way to limit the consequences. I
expect that we also need to fix a few testcases in separate revisions.
Bert
Sent from Mail for Windows 10
From: Johan Corveleyn
Sent: dinsdag 16 mei 2017 12:17
To: Subversion Development
Cc: Stefan Fuhrmann; Bert Huijben
Subject: Re: stricter text conflicts in 1.10
On Sat, May 13, 2017 at 10:38 PM, Stefan Fuhrmann <stef...@apache.org> wrote:
> On 09.05.2017 12:14, Stefan Sperling wrote:
>>
>> I have seen several instances of proposals in our STATUS file where I
>> cannot merge without text conflicts because I am using a trunk client.
>>
>> I suppose most of us use 1.9.x clients to do such merges, because
>> otherwise there would be a lot more backport branches in STATUS when
>> nominations get added, and before I run into such a conflict.
>>
>> This is probably due to the stricter text conflict checks added in
>> r1731699.
>> If so, are we really sure that we want to make the new behaviour the
>> default?
>> I can imagine that in organizations with a diverse SVN client install base
>> this change will cause a lot of misunderstandings and confusion among
>> users.
>>
>> And with the conflict resolver we are trying to make tree conflicts less
>> painful. Now, at the same time text conflicts have become a lot more
>> painful
>> than they used to be. I don't think this is going to be a good sell.
>>
> I'm strongly against producing additional text conflicts.
> My feeling is that 1.9 (1.8?) already produces more of
> those than prior releases did and it annoys me.
>
> If we missed a reasonable corner case - by all means
> get that fixed. But don't break the reasonably well
> working cases.
+1. Unless someone has an idea how to improve on r1731699 [1] to avoid
"unnecessary conflicts", I guess we should revert it. Bringing back
the edge case ("controversial behavior discussed in 2003") that
r1731699 fixed is probably the lesser of two evils, compared to the
additional conflicts it introduces.
Bert, WDYT?
[1] http://svn.apache.org/r1731699
--
Johan
RE: svn commit: r1794632 - /subversion/trunk/notes/sha1-advisory.txt
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: woensdag 10 mei 2017 13:34 > To: Daniel Shahaf <d...@daniel.shahaf.name> > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1794632 - /subversion/trunk/notes/sha1- > advisory.txt > > On Wed, May 10, 2017 at 09:11:50AM +, Daniel Shahaf wrote: > > > Summary: > > > > > > > > > Subversion repositories can be corrupted by committing two files > > > which have different content, yet produce the same SHA1 checksum. > > > > I don't think we should call this "corruption": the on-disk data > > structures are intact, both syntactically and semantically. The problem > > is in the libraries' assumption that sha1 has no collisions. > > > > I'm afraid I don't have a good suggestion; perhaps "Distinct files that > > have equal sha1 checksums cannot be checked out"? > > I think we should call it corruption simply because it looks like > that to our users when it happens (see webkit). > > This is a user-facing text. We want users to take action and upgrade so > they won't run into the problem. The purpose of this text is to raise > awareness. It is not to communicate technical details of the problem, > which can be obtained by other means (reading code, mailing lists, etc.) > > I expect "corruption" will turn on people's alarm bells more than your > suggested wording which is very exact but also sounds less dramatic. Those alarm bells are the reason why I wouldn't call it corruption, as that part will probably be highlighted in the media, while there is nothing corrupt on disk. Bert
RE: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: dinsdag 9 mei 2017 11:26 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS > > On Tue, May 09, 2017 at 09:13:57AM +0200, Bert Huijben wrote: > > I haven’t investigated this any further, but do we now try to start the > > gpg-agent on every invocation of a command just to poll if we perhaps > have a > > GPG agent running, and might want to use that authentication option? > > No. gpgconf is not gpg-agent. > gpgconf is a tool for querying configuration parameters of gnupg. > https://www.gnupg.org/documentation/manuals/gnupg/gpgconf.html#gpg > conf > > No agent is started when I run this: > $ gpgconf --list-dir agent-socket > /home/stsp/.gnupg/S.gpg-agent But 'gpgpconf' is started. The problem is that we just start external code... Which executable doesn't matter that much. Subversion is a library and we should be very careful about this. I think this code is by default left out on Windows, but there are tons of cert reports where just loading a library dynamically to test something is a security problem, and just running an executable is far worse. I don't see a problem with enabling this if we know the user uses gpg, but doing this on every auth request just to see if gpg can theoretically be used as backend is too much for me. The function to test if there is a gpg store becomes several orders of magnitude slower, while we don't even cache the result... because the code used to be blazingly fast The code forks the process, which may have severe consequences in certain environments involving threads (running inside Eclipse?) This is no longer some small trivial change... It changes outside dependencies and security boundaries. Bert
RE: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS
I haven’t investigated this any further, but do we now try to start the gpg-agent on every invocation of a command just to poll if we perhaps have a GPG agent running, and might want to use that authentication option? I don’t think we want to do that as a simple replacement of a cheap check of an environment variable as we did before. There is also a long list of applications where just executing a program by name (without path or anything) is called a security problem. Bert Sent from Mail for Windows 10 From: james...@apache.org Sent: maandag 8 mei 2017 19:56 To: comm...@subversion.apache.org Subject: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS Author: jamessan Date: Mon May 8 17:56:35 2017 New Revision: 1794433 URL: http://svn.apache.org/viewvc?rev=1794433=rev Log: * STATUS: Nominate r1794166. Modified: subversion/branches/1.9.x/STATUS Modified: subversion/branches/1.9.x/STATUS URL: http://svn.apache.org/viewvc/subversion/branches/1.9.x/STATUS?rev=1794433=1794432=1794433=diff == --- subversion/branches/1.9.x/STATUS (original) +++ subversion/branches/1.9.x/STATUS Mon May 8 17:56:35 2017 @@ -89,6 +89,14 @@ Candidate changes: Votes: +1: stefan2, rhuijben + * r1794166 + Find gpg-agent socket using gpgconf, if possible. + Justification: + Improves GPG socket detection when $GPG_AGENT_INFO is unset or when gpg + >= 2.1.13 is used + Votes: + +1: jamessan + Veto-blocked changes: =
RE: 'svnadmin load-revprops' as first-level command?
Perhaps the revprop load operation was designed to support some kind of 'refresh' of the revprops after an earlier dump/sync. In that case it might make sense to have a specific operation, as that would really change the operation to something completely else. Bert From: Markus Schaber <m.scha...@codesys.com> Sent: Wednesday, April 26, 2017 8:25:58 AM To: Daniel Shahaf; dev@subversion.apache.org Subject: RE: 'svnadmin load-revprops' as first-level command? Hi, From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > I was going through the 1.10 release notes and I found the new load-revprops > / dump-revprops subcommands: > > https://subversion.apache.org/docs/release-notes/1.10#svnadmin-revprops > New svnadmin dump-revprops and svnadmin load-revprops subcommands > > […] svnadmin dump-revprops will save the current values of all > revision properties to a dump file. svnadmin load-revprops can be > used to set revision properties in a repository to the values saved > in a dump file. > > I don't dispute the need for such functionality, but is a separate top-level > command the right home for it? I would have expected 'load-revprops' to be > spelled "svnadmin load --only-revprops" or even "svndumpfilter revprops-only > | svnadmin load". > > The rationale is that 'load' and 'load-revprops' take exactly the same data > format and manipulate it in exactly the same way. I guess that, especially for the "dump" case, "dump-revprops" is (or should be) much more efficient than a "dump" piped through "svndumpfilter". For "load", the additional overhead will be smaller, but still there. So I think this functionality should be implemented in svnadmin itself. Note, however, that I wouldn't mind it being an "--only-revprops" option to the existing "load" and "dump" subcommands instead of a new subcommand. And I also don't oppose the idea of "svndumpfilter revprops-only", which clearly has its own use cases. :-) Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Progress on SHA-1 fixes in patch releases?
The server side fixes currently need a third vote for backporting. These fixes are nominated for 1.8.x and 1.9.x. I don’t think we can really do much more on the released versions without a backwards incompatible change to the working copy… And I’m still not convinced that we should really change the WC code just to support using Subversion to explicitly store collisions. On trunk there are even more problems, as Ivan committed a change that made us rely on sha-1 even more than before to check for local changes. I already pinged that thread a few times, but there is no progress there. If no progress is reported on the discussed points I would like to see that change to notice differences (at least temporarily) reverted. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: donderdag 30 maart 2017 13:23 To: Paul Hammant Cc: Subversion Development Subject: Re: Progress on SHA-1 fixes in patch releases? On Thu, Mar 30, 2017 at 06:30:55AM -0400, Paul Hammant wrote: > My apologies. When I wrote "No patch releases though, right?" my intention > was to communicate "No patch releases YET though, right? There are no patch releases yet, no.
RE: svn commit: r1786446 - /subversion/trunk/subversion/libsvn_fs_fs/transaction.c
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: vrijdag 10 maart 2017 21:57 > To: comm...@subversion.apache.org > Subject: svn commit: r1786446 - > /subversion/trunk/subversion/libsvn_fs_fs/transaction.c > > Author: stefan2 > Date: Fri Mar 10 20:56:59 2017 > New Revision: 1786446 > > URL: http://svn.apache.org/viewvc?rev=1786446=rev > Log: > * subversion/libsvn_fs_fs/transaction.c > (get_shared_rep): Don't leak error objects. > > Found by: danielsh > > Modified: > subversion/trunk/subversion/libsvn_fs_fs/transaction.c > > Modified: subversion/trunk/subversion/libsvn_fs_fs/transaction.c > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/tra > nsaction.c?rev=1786446=1786445=1786446=diff > == > > --- subversion/trunk/subversion/libsvn_fs_fs/transaction.c (original) > +++ subversion/trunk/subversion/libsvn_fs_fs/transaction.c Fri Mar 10 > 20:56:59 2017 > @@ -2429,9 +2429,6 @@ get_shared_rep(representation_t **old_re >err = svn_stream_contents_same2(, contents, old_contents, >scratch_pool); > > - /* Restore FILE's read / write position. */ > - SVN_ERR(svn_io_file_seek(file, APR_SET, _position, scratch_pool)); > - >/* A mismatch should be extremely rare. > * If it does happen, log the event and don't share the rep. */ >if (!same || err) > @@ -2462,6 +2459,9 @@ get_shared_rep(representation_t **old_re >svn_error_clear(err); >*old_rep = NULL; > } > + > + /* Restore FILE's read / write position. */ > + SVN_ERR(svn_io_file_seek(file, APR_SET, _position, scratch_pool)); I'm not sure if that is a safe fix... Need more context for that. You could just have used svn_error_compose_create() and combine both errors. Bert
RE: buildbot failure in on svn-warnings
Hi Greg, For now I disabled the '--with-berkeley-db', '--with-sasl', '--with-libmagic', in our buildbot configuaration to have the build pass. Can you re-enable these once the missing packages are installed? (Is there some issue where I can add this information?) Bert From: Greg Stein [mailto:gst...@gmail.com] Sent: woensdag 30 november 2016 03:41 To: dev@subversion.apache.org Subject: Re: buildbot failure in on svn-warnings With the move off of hemera, we're missing packages. I'm working on that, along with a few changes to the svn-warnings buildbot code (simplifying, so far). On Tue, Nov 29, 2016 at 7:45 PM, <build...@apache.org <mailto:build...@apache.org> > wrote: The Buildbot has detected a new failure on builder svn-warnings while building . Full details are available at: https://ci.apache.org/builders/svn-warnings/builds/1687 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: bb_qnode4_ubuntu Build Reason: forced: by IRC user on channel #svn-dev: None Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed Configure Sincerely, -The Buildbot
RE: translations (let's use Transifex or Pootle)
> -Original Message- > From: Julian Foad [mailto:jul...@foad.me.uk] > Sent: vrijdag 10 februari 2017 12:48 > To: Andreas Stieger <andreas.stie...@gmx.de> > Cc: Branko Čibej <br...@apache.org>; dev@subversion.apache.org > Subject: Re: translations (let's use Transifex or Pootle) > > > Andreas Stieger wrote: > >> [Pootle] worked sufficiently well for strings that have no special > >> formatting requirements. It also worked well for out-of-band changes, > >> e.g. merging items translated locally with those translated in Pootle. > >> > >> For anything that includes non-trivial help output and special > >> formatting, I found it to be cumbersome. > [...] > >> You would not use the .pot but the .po, so as to not loose existing > >> translations. > >> For other translations: setting them up in Pootle, I did not want to > >> presume that other po maintainers would want to do that. > >> > >> Pootle has automation opportunities of scanning the code base, have not > >> explored. > >> > >> Is that something we want to kick off for the next release? > > Andreas, thanks for your thoughts. It sounds like your overall > experience of using Pootle was that it was useful but not great. > > Also I see that OpenOffice is the *only* project really using Apache's > Pootle: other than that and Subversion (German only), there is just > JMeter (French only) and two projects that have no major activity. > > So the major reason I assumed we should use it -- because I assumed it > was the standard tool for Apache projects -- evaporates. How about we > use transifex (https://www.transifex.com/) then, because it's what > TortoiseSVN is using? For some initial testing I uploaded the current set of resources on trunk to transifex. They are now available on: https://www.transifex.com/apache-subversion/apache-subversion/ Feel free to request an account to play with these. I'm still working on automating the update system two ways, but for now it appears to work... After fixing a few plural form problems in our existing po files all languages except Swedish are now stored as they should be. For some reason Transifex doesn't want me to update Swedish 'sv' resources, but does allow Swedish-Sweden 'sv_SE' rersources. Bert > > Branko Čibej wrote: > > It wouldn't hurt to bring Subversion into the 20th century, at least as > > far as translations are concerned. :) > > +1 > > > I can help with any scripting but can't promise to lead this effort ... > > NoTimeTM. > > Thanks! (And me too.) > > - Julian
RE: translations (buildbot to update translatable strings)
> -Original Message- > From: Julian Foad [mailto:julianf...@apache.org] > Sent: maandag 13 maart 2017 11:53 > To: Stefan Kueng <tortoise...@gmail.com> > Cc: Subversion Development <dev@subversion.apache.org> > Subject: Re: translations (buildbot to update translatable strings) > > Stefan K, trying to help push this forward... > > We have consensus to do something about automatically providing updates > to translatable strings. We need some help to fill in the details and > actually do it. > > From my perspective, it looks like we should: > > * Instantiate a bot (buildbot) that will... >- do we have a volunteer? > >* Check out the trunk (and any configured branches). > >* Run 'make po-update'. If nobody else steps up, I can handle this part. >* (?) Upload the updated 'subversion.pot' and/or '*.po' files > to services including Pootle and Transifex. > - how exactly should it upload to Pootle? > - how exactly should it upload to Transifex? Also willing to work on this part, after we have that info. >* (?) Commit the updated 'subversion.pot' and/or '*.po' files. > - which files? when (see below)? > > * Activate a Transifex.com account for Subversion. >- how? can you do it? > > Re committing: I think we should rate-limit these commits to once per > day, and should not commit when there are no real changes to the > translatable strings but only changes in the source line number > reference comments. > > An alternative to committing would be to upload these files to some > place where translators can fetch them. Somewhere on apache.org and/or > if the Pootle and/or Transifex services make these files easily > available then that's fine, we can point at those, no need to commit. >- Do they? What are the URLs? I would start with this second scheme... Perhaps even add an option to one of our scripts to fetch the latest version at [build/invoke], for easy testing and committing around releases. Not sure if we should really start auto commits on our tree... Don't see a good use for these auto commits on trunk, as that code is seldom used in production... And I would like to be careful with our release branches, on not creating too many unneeded commits that could be collapsed... Bert
RE: Files with identical SHA1 breaks the repo
The whole idea of the pristine cache is handling duplicate files… I don’t see what you are trying to solve by adding a salt. The pristine store is not a password store, where expensive hashing is a good feature… not a user facing slowdown and we never designed Subversion as a storage area for collision files. That there is a collision now doesn’t change that we always assumed there would be collisions, and designed the current behavior with that in mind. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: vrijdag 24 februari 2017 21:47 To: Mark Phippard Cc: Øyvind A. Holm; Subversion Development Subject: Re: Files with identical SHA1 breaks the repo On Fri, Feb 24, 2017 at 01:03:09PM -0500, Mark Phippard wrote: > Note that while this does fix the error, but because of the sha1 storage > sharing in the working copy you actually do not get the correct files. > Both PDF's wind up being the same file, I imagine whichever one you receive > first is the one you get. > > So not only does rep sharing need to be fixed, the WC pristine storage is > also broken by this. Yes, indeed. I believe we should prepare a new working format for 1.10.0 which addresses this problem. I don't see a good way of fixing it without a format bump. The bright side of this is that it gives us a good reason to get 1.10.0 ready ASAP. We can switch to a better hash algorithm with a WC format bump. If we are willing to dispose of de-duplication in the pristine store we could make the pristine store future proof by adding a "salt" to each row in the pristine table. Say 64 bytes of data prepended to file content, which are random but stay fixed throughout the lifetime of a pristine. This way, there are 64 bytes of data not controlled by repository content which affect the hash algorithm's result before data from repository content gets mixed in. Now hash collisions in repository content become much less of a problem for the working copy. However, the pristine store would stop de-duplicating content. So perhaps this is not the best approach. The rep-cache uses hashes only for de-duplication so it very much relies on hash collisions being negligible. We should upgrade the hashing algorithm in a way that 'svnadmin upgrade' can take care of (for new revisions). Perhaps we should disable the feature by default in a 1.9.x patch release and advise users to turn it off until they can upgrade to 1.10. We might have to give up on ra_serf's approach of avoiding retransmissions of content which is already stored in the pristine store. This is now just as broken as the rep-cache is. We might be able to salvage it for future clients, but we should probably send multiple hashes and make it as easy as possible to add newer hash algorithms in future versions without disturbing older clients. Perhaps as a first step we should just disable this feature?
RE: Files with identical SHA1 breaks the repo
I remember some experiments in early development of WC-NG where we measured which checksums worked vs which ones were too expensive. Going to the SHA1 family was at least 5 times more expensive or so… We determined back then SHA1 was good enough for our use and that of our users ‘except for those doing collision research’. Just adding more checksums internally, because we can won’t help our users… The only real solution is doing full comparisons when checksums match… Which virtually never happens. It happened for the first time now, so most likely never before for all of the Subversion users together. This is how we used MD5 before… But we determined SHA1 would be good enough to avoid this, even when such a collision would be found… as it is today. I don’t think this incident changes those original ideas about which hash is good enough… Perhaps some careful re-evaluation is necessary, but I don’t think we should just ‘fix this’ by bumping everything to the next hashtype. This ‘just use a more expensive hash’ may be a good approach for other users of hashes, but I don’t think we want to make every common Subversion operations much slower because there is one collision found using an insane amount of CPU/GPU power. Of course we should fix things to not break, but that is a different story. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: vrijdag 24 februari 2017 17:10 To: Andreas Stieger Cc: Subversion Development Subject: Re: Files with identical SHA1 breaks the repo On Fri, Feb 24, 2017 at 04:17:44PM +0100, Andreas Stieger wrote: > Hi, > > "Stefan Hett" wrote: > > On 2/23/2017 9:02 PM, Øyvind A. Holm wrote: > > > This is the only known SHA-1 collision at the moment, but Google will > > > release the collision code in 90 days, so we can expect this not to last > > > forever. > > Reading up on that in an article on a German magazine [1] clarifies that > > the effort to create that hash still quite large (6500 CPU years + 100 > > GPU years to calculate the collision). So this relativates the impact a bit. > > Certainly I'm not trying to say that the situation on SVN's side > > should/could not be improved, though. > > > > [1] > > https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html > > An occurrence of this issue in a production repository with the published > PDFs: > https://bugs.webkit.org/show_bug.cgi?id=168774#c29 > > Andreas Well, what did they expect? Did they expect that all software which is part of their toolchain has ever been tested with files that produce a SHA1 collision? Nobody had such files until yesterday... They should have tried this on a test repository first. Anyway, so SVN has multiple problems with SHA1 collisions. One problem is that the libsvn_wc code does the wrong thing when SHA1 hashes match but MD5 hashes do not. The error on checkout is happening because pristines are keyed on SHA1, and only one pristine is saved: $ ls .svn/pristine/ 38/ $ ls .svn/pristine/38/ 38762cf7f55934b34d179ae6a4c80cadccbb7f0a.svn-base $ sha1 .svn/pristine/38/38762cf7f55934b34d179ae6a4c80cadccbb7f0a.svn-base SHA1 (.svn/pristine/38/38762cf7f55934b34d179ae6a4c80cadccbb7f0a.svn-base) = 38762cf7f55934b34d179ae6a4c80cadccbb7f0a $ md5 .svn/pristine/38/38762cf7f55934b34d179ae6a4c80cadccbb7f0a.svn-base MD5 (.svn/pristine/38/38762cf7f55934b34d179ae6a4c80cadccbb7f0a.svn-base) = ee4aa52b139d925f8d8884402b0a750c By design, the current working copy format cannot store both of these PDFs. This is hard to solve without a working copy format bump :-/ The best fix would probably be moving libsvn_wc to SHA256 or SHA3. FSFS looks alright. The node records for these two PDFs look like this: [[[ id: 0-1.0.r1/5 type: file count: 0 text: 1 3 381130 422435 ee4aa52b139d925f8d8884402b0a750c 38762cf7f55934b34d179ae6a4c80cadccbb7f0a 0-0/_3 props: 1 4 56 44 cfa89e28d5298bc69638e814df40c883 cpath: /shattered-1.pdf copyroot: 0 / id: 2-1.0.r1/6 type: file count: 0 text: 1 3 381130 422435 5bd9d8cabc46041579a311230539b8d1 38762cf7f55934b34d179ae6a4c80cadccbb7f0a 0-0/_4 props: 1 4 56 44 cfa89e28d5298bc69638e814df40c883 cpath: /shattered-2.pdf copyroot: 0 / ]]] We should look into making the FSFS code make use of both checksums to handle ambiguities. It seems about time to add SHA256 and/or SHA3 as well. 'svnadmin load' fails, too: $ svnadmin create repo2 $ vi repo repo/ repo2/ $ vi repo2/db/fs fs-typefsfs.conf $ vi repo2/db/fsfs.conf # disable rep-sharing $ svnadmin dump repo > repo.dump * Dumped revision 0. * Dumped revision 1. $ svnadmin load repo2 < repo.dump <<< Started new transaction, based on original revision 1 * editing path : shattered-1.pdf ... done. * editing path : shattered-2.pdf ...subversion/libsvn_repos/load.c:709, subversion/libsvn_repos/load.c:351, subversion/libs
RE: Bug in "svnrdump" ?
That code is in the backing code for svn_ra_replay(), where it also applies to authz, not on the client. @Julian Foad Can we use svnsync in this scenario, or does that break in a similar way? Bert Sent from Mail for Windows 10 From: Julian Foad Sent: woensdag 22 februari 2017 15:11 To: Doug Robinson Cc: dev Subject: Re: Bug in "svnrdump" ? Doug Robinson wrote: > This has been reproduced on 1.9.5 and 1.8.16. I've attached a dump of > the simple test case repo. Thanks. I was hasty -- I see what's going on. This is dumping a subtree of the repo (/B/Trunk), and r2 was not dumped because it doesn't touch the subtree, and it fails on r3 corresponding to step 3. This feature (dump a subtree) is not possible with 'svnadmin dump'. So the bug is that svnrdump doesn't know how to handle a copy source that's outside the subtree being dumped. That's rather poor. I believe the desired behaviour would be to replace the 'copy' with a full 'add', and I believe that behaviour is implemented somewhere else -- is it in svndumpfilter and/or svnsync? If you could file a bug report that would be very helpful, thanks. - Julian > If so then it has a reproducible bug: > -- > 1. Add following files into an empty repo. > >A /A > >A /A/AA > >A /A/AA/a.txt > >A /A/AA/b.txt > > 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt > >A /B (from /A:1) > >D /B/AA/a.txt > > 3. Copy folder B/AA to folder B/Trunk/AA > >A /B/Trunk > >A /B/Trunk/AA (from /B/AA:2) > > 4. run svnrdump command to dump B/Trunk folder. > > # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump > > * Dumped revision 0. > > * Dumped revision 1. > > svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt' > -- > > Is this known already? Should I file a bug?
RE: svn commit: r1783953 - /subversion/site/publish/docs/release-notes/1.10.html
> -Original Message- > From: jcor...@apache.org [mailto:jcor...@apache.org] > Sent: dinsdag 21 februari 2017 23:35 > To: comm...@subversion.apache.org > Subject: svn commit: r1783953 - /subversion/site/publish/docs/release- > notes/1.10.html > > Author: jcorvel > Date: Tue Feb 21 22:34:48 2017 > New Revision: 1783953 > > URL: http://svn.apache.org/viewvc?rev=1783953=rev > Log: > * publish/docs/release-notes/1.10.html: > (#conflict-resolver): generalize local change "delete directory" to >"delete item". Usually we use the term 'node' to describe 'some thing in the working copy' instead of item. Bert
RE: 1.10.0-alpha1 is up for signing
If you compare this problem to 1.7 or something it wouldn’t be a regression. MSBuild by default builds all targets in the makefile, if you don’t pass a target via the optional -t argument. In those older versions we always generated targets that depended hard on optional dependencies, so building everything didn’t work… You really had to specify a target like __ALL_TESTS__, to avoid things like the swig code, bdb or cxxhl failing. Since that problem was fixed some time ago, we now fail on systems that just build everything… while those that still specify a target like our buildbots that were setup to be compatible with those old setups don’t see this problem. Note that I don’t think the unix makefiles build everything either… so they may have similar problems somewhere. But +1 on rerolling anyway. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: dinsdag 21 februari 2017 11:28 To: Evgeny Kotkov Cc: Stefan Hett; Subversion Development Subject: Re: 1.10.0-alpha1 is up for signing On Tue, Feb 21, 2017 at 01:18:01PM +0300, Evgeny Kotkov wrote: > Stefan Hett <luke1...@posteo.de> writes: > > > Trying to build this release triggers the following build error when > > compiling the svn-mergeinfo-normalizer tool for me: > > > > ..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376): > > error C4013: 'svn_hash__sets' undefined; assuming extern returning int > > I can confirm that 1.10.0-alpha1 doesn't build on Windows in my environment > (the svn-mergeinfo-normalizer tool is built by default). > > I committed r1783859 and r1783862 in order to fix this issue. Perhaps, we > should roll alpha2 with these fixes? > > > Regards, > Evgeny Kotkov Thanks for fixing this Evgeny! I agree we should prepare another release and toss alpha1, given that alpha1 does not compile everywhere. I'll do that today.
Re: Check SHA vs Content (was: RE: svn commit: r1759233 - /subversion/trunk/subversion/libsvn_wc/questions.c)
This code is still in trunk without any of the discussed improvements, so this change is currently part of 1.10.0-alpha1. If we don't implement the improvements I think we should check if we want to revert to the 1.0-1.9 behavior before we really look at releasing 1.10. See discussion below Bert On Thu, Sep 8, 2016 at 5:42 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > On 5 September 2016 at 19:23, Ivan Zhakov <i...@visualsvn.com> wrote: > > On 5 September 2016 at 14:46, Bert Huijben <b...@qqmail.nl> wrote: > >>> -Original Message- > >>> From: i...@apache.org [mailto:i...@apache.org] > >>> Sent: maandag 5 september 2016 13:33 > >>> To: comm...@subversion.apache.org > >>> Subject: svn commit: r1759233 - > >>> /subversion/trunk/subversion/libsvn_wc/questions.c > >>> > >>> Author: ivan > >>> Date: Mon Sep 5 11:32:54 2016 > >>> New Revision: 1759233 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1759233=rev > >>> Log: > >>> Use SHA-1 checksum to find whether files are actually modified in > working > >>> copy if timestamps don't match. > >>> > >>> Before this change we were doing this: > >>> 1. Compare file timestamps: if they match, assume that files didn't > change. > >>> 2. Open pristine file. > >>> 3. Read properties from wc.db and find whether translation is required. > >>> 4. Compare filesize with pristine filesize for files that do not > >>>require translation. Assume that file is modified if the sizes > differ. > >>> 5. Compare detranslated contents of working file with pristine. > >>> > >>> Now behavior is the following: > >>> 1. Compare file timestamps: if they match, assume that files didn't > change. > >>> 3. Read properties from wc.db and find whether translation is required. > >>> 3. Compare filesize with pristine filesize for files that do not > >>>require translation. Assume that file is modified if the sizes > differ. > >>> 4. Calculate SHA-1 checksum of detranslated contents of working file > >>>and compare it with pristine's checksum stored in wc.db. > >> > > Hi Bert, > > > >> We looked at this before, and this change has pro-s and con-s, > depending on specific use cases. > >> > > Thanks for bringing this to dev@ list, I was not aware that this topic > > was discussed before. > > > [...] > > >> If the file happens to be a database file or something similar > >> there is quite commonly a change in the first 'block', when > >> there are changes somewhere later on. (Checksum, change > >> counter, etc.). File formats like sqlite were explicitly designed > >> for this (and other cheap checks), with a change counter at the start. > > > >> I don't think we should 'just change behavior' here, if we don't > >> have actual usage numbers for our users. Perhaps we should make > >> this feature configurable... or depending on filesize. > >> > > > > Let me summarize all possible cases that I considered before my > > change. First of all some definitions: > > * Text file (T) -- text file that require translation, due to eol > > style or keywords expansion > > * Text file (N) -- text file that doesn't require translation > > * Binary file -- some kind of binary file (database, pdf, zip, docx). > > Let's assume that user doesn't configure svn:eol-style and > > svn:keywords for them. > > * WS -- size of working file > > * PS -- size of pristine file > > > > * Old=xxx -- average required read size for old behavior in terms of > > working and pristine file sizes > > * New=xxx -- average required read size for new behavior in terms of > > working and pristine file sizes > > > > 1. Text file (T), not modified: Old = WS + PS, New = WS > > 2. Text file (N), not modified: Old = WS + PS, New = WS > > 3. Binary file, not modified: Old = WS + PS, New = WS > > 4. Text file (T), modified, same size: Old = 0.5 * WS + 0.5 * PS, New = > WS > > 5. Text file (N), modified, same size: Old = 0.5 * WS + 0.5 * PS, New = > WS > > 6. Binary file, modified, same size: Old = 0.5 * WS + 0.5 * PS, New = WS > > 7. Text file (T), modified, different size: Old = 0.5 * WS + 0.5 * PS, > New = WS > > 8. Text file (N), modified, different size: Old = 0, New = 0 > > 9. Binary file, modified, different size: Old = 0, New = 0 > > > Hi Bert, > > I tested several d
RE: svn commit: r1779617 - /subversion/trunk/subversion/libsvn_ra_svn/client.c
> -Original Message-
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: vrijdag 20 januari 2017 13:34
> To: comm...@subversion.apache.org
> Subject: svn commit: r1779617 -
> /subversion/trunk/subversion/libsvn_ra_svn/client.c
>
> Author: stefan2
> Date: Fri Jan 20 12:33:32 2017
> New Revision: 1779617
>
> URL: http://svn.apache.org/viewvc?rev=1779617=rev
> Log:
> Second and final step in the eliminatation of reparent calls over ra_svn.
>
> Actually eliminate reparent calls that are below to the current parent.
> Adapt all path parameter accordingly before passing them to the server.
This patch introduces a few calls to dirent functions, that should really be to
relpath functions. The buildbot complains with assertions on Windows, as we
explicitly test for a few of these cases.
Bert
> Modified:
> subversion/trunk/subversion/libsvn_ra_svn/client.c
>
> Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/c
> lient.c?rev=1779617=1779616=1779617=diff
> ==
>
> --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Jan 20 12:33:32
> 2017
> @@ -936,6 +936,92 @@ reparent_server(svn_ra_session_t *ra_ses
>return SVN_NO_ERROR;
> }
>
> +/* Make sure that RA_SESSION's client and server-side parent infp are in
> + sync. Use SCRATCH_POOL for temporary allocations. */
> +static svn_error_t *
> +ensure_exact_server_parent(svn_ra_session_t *ra_session,
> + apr_pool_t *scratch_pool)
> +{
> + svn_ra_svn__session_baton_t *sess = ra_session->priv;
> + svn_ra_svn__parent_t *parent = sess->parent;
> +
> + /* During e.g. a checkout operation, many requests will be sent for the
> + same URL that was used to create the session. So, both sides are
> + often already in sync. */
> + if (svn_stringbuf_compare(parent->url, parent->server_base_url))
> +return SVN_NO_ERROR;
> +
> + /* Actually reparent the server to the session URL. */
> + SVN_ERR(reparent_server(ra_session, parent->url->data, scratch_pool));
> + svn_stringbuf_setempty(parent->path);
> +
> + return SVN_NO_ERROR;
> +}
> +
> +/* Return a copy of PATH, adjusted to the RA_SESSION's server parent URL.
> + Allocate the result in RESULT_POOL. */
> +static const char *
> +reparent_path(svn_ra_session_t *ra_session,
> + const char *path,
> + apr_pool_t *result_pool)
> +{
> + svn_ra_svn__session_baton_t *sess = ra_session->priv;
> + svn_ra_svn__parent_t *parent = sess->parent;
> +
> + return svn_dirent_join(parent->path->data, path, result_pool);
This should join relpaths, not dirents...
> +}
> +
> @@ -943,18 +1029,35 @@ static svn_error_t *ra_svn_reparent(svn_
>svn_ra_svn__session_baton_t *sess = ra_session->priv;
>svn_ra_svn__parent_t *parent = sess->parent;
>svn_ra_svn_conn_t *conn = sess->conn;
> + const char *path;
>
> - /* Eliminate redundant reparent requests. */
> - if (strcmp(parent->server_base_url->data, url))
> -{
> - /* Send the request to the server. */
> - SVN_ERR(reparent_server(ra_session, url, pool));
> + /* Eliminate reparent requests if they are to a sub-path of the
> + server's current parent path. */
> + path = svn_dirent_skip_ancestor(parent->server_base_url->data, url);
> + if (!path)
> +{
> + /* Send the request to the server.
> +
> + If within the same repository, reparent to the repo root
> + because this will maximize the chance to turn future reparent
> + requests into a client-side update of the rel path. */
> + path = conn->repos_root
> + ? svn_dirent_skip_ancestor(conn->repos_root, url)
> + : NULL;
Same problem.
> +
> + if (path)
> +SVN_ERR(reparent_server(ra_session, conn->repos_root, pool));
> + else
> +SVN_ERR(reparent_server(ra_session, url, pool));
> }
> @@ -1502,12 +1610,14 @@ static svn_error_t *ra_svn_get_mergeinfo
> apr_pool_t *pool)
> {
>svn_ra_svn__session_baton_t *sess_baton = session->priv;
> + svn_ra_svn__parent_t *parent = sess_baton->parent;
>svn_ra_svn_conn_t *conn = sess_baton->conn;
>int i;
>svn_ra_svn__list_t *mergeinfo_tuple;
>svn_ra_svn__item_t *elt;
>const char *path;
>
> + paths = reparent_path_array(session, paths, pool);
>SVN_ERR(svn_ra_svn__write_tuple(conn,
RE: svn commit: r1776846 - /subversion/trunk/build.conf
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: zondag 1 januari 2017 13:18 > To: comm...@subversion.apache.org > Subject: svn commit: r1776846 - /subversion/trunk/build.conf > > Author: stefan2 > Date: Sun Jan 1 12:18:25 2017 > New Revision: 1776846 > > URL: http://svn.apache.org/viewvc?rev=1776846=rev > Log: > Fix yet another symbol export issue under Windows. > > * build.conf > (libsvn_repos): Make sure to export private symbols needed by our tests. As you don't note which test this applies to: there are other ways to fix tests than making functions exported. Some of our tests explicitly link statically to our libraries to have complete access to usually private functions. I think this is now configured in build.conf, but there used to be some magic name requirement to trigger this behavior. Bert
RE: 1.8.17 up for signing/testing
> -Original Message- > From: Stefan Fuhrmann [mailto:eq...@web.de] > Sent: zaterdag 26 november 2016 10:39 > To: dev@subversion.apache.org > Subject: Re: 1.8.17 up for signing/testing > > On 21.11.2016 16:30, Evgeny Kotkov wrote: > > The 1.8.17 release artifacts are now available for testing/signing. > > Please get the tarballs from > > https://dist.apache.org/repos/dist/dev/subversion > > and add your signatures there. I plan to try and release on November 29th > > so please try and get your votes/signatures in place by November 28th. +1 for release Platform: Windows 8.1 Enterprise x86-x64, Visual Studio 2015 Update 3 Tested [fsfs|bdb] x [local|serf|svn] (32 bit) apr 1.5.1 apr-util 1.5.4 apr_memcache 1.5.4 bdb 4.4.20 expat 2.2.0 httpd 2.4.18 java-sdk 1.8.0_40 mod_dav 2.4.18 openssl 1.0.2j cyrus sasl 2.1.26 serf 1.3.9 sqlite 3.15.1 zlib 1.2.8 cmake 3.6.2 scons 2.5.0 junit 4.10 All tests passed (after some initial problems starting this VM) Signatures committed Bert Huijben
RE: 1.9.5 up for signing/testing
+1 for release Platform: Windows 8.1 Enterprise x86-x64, Visual Studio 2015 Update 3 Tested [fsfs|bdb] x [local|serf|svn] (32 bit) apr 1.5.1 apr-util 1.5.4 apr_memcache 1.5.4 bdb 4.4.20 expat 2.2.0 httpd 2.4.18 java-sdk 1.8.0_40 mod_dav 2.4.18 openssl 1.0.2j cyrus sasl 2.1.26 serf 1.3.9 sqlite 3.15.1 zlib 1.2.8 All tests passed (after some initial problems starting this VM) Signatures committed Bert Huijben > -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: maandag 21 november 2016 16:31 > To: Subversion Development <dev@subversion.apache.org> > Subject: 1.9.5 up for signing/testing > > The 1.9.5 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. I plan to try and release on November 29th > so please try and get your votes/signatures in place by November 28th. > > Thanks!
RE: svn commit: r1770633 - in /subversion/trunk/subversion: libsvn_wc/wc_db_update_move.c tests/libsvn_client/conflicts-test.c
> -Original Message-
> From: s...@apache.org [mailto:s...@apache.org]
> Sent: maandag 21 november 2016 10:37
> To: comm...@subversion.apache.org
> Subject: svn commit: r1770633 - in /subversion/trunk/subversion:
> libsvn_wc/wc_db_update_move.c tests/libsvn_client/conflicts-test.c
>
> Author: stsp
> Date: Mon Nov 21 09:36:30 2016
> New Revision: 1770633
>
> URL: http://svn.apache.org/viewvc?rev=1770633=rev
> Log:
> Fix a trivial bug in the update-incoming-move code.
>
> * subversion/libsvn_wc/wc_db_update_move.c
> (update_incoming_moved_node): Look at the correct WC relpath for the
> conflict
>victim's set of working nodes.
>
> * subversion/tests/libsvn_client/conflicts-test.c
> (test_list): Mark test_update_incoming_dir_move_with_nested_file_move as
> PASS.
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/wc_db_update_move.c
> subversion/trunk/subversion/tests/libsvn_client/conflicts-test.c
>
> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_update_move.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_u
> pdate_move.c?rev=1770633=1770632=1770633=diff
>
> ==
> --- subversion/trunk/subversion/libsvn_wc/wc_db_update_move.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db_update_move.c Mon Nov
> 21 09:36:30 2016
> @@ -2059,7 +2059,7 @@ update_incoming_moved_node(node_move_bat
> src_relpath, b->src_op_depth, wcroot, scratch_pool,
> scratch_pool));
>SVN_ERR(get_working_info(_props, _checksum,
> - _children, _kind, dst_relpath,
> + _children, _kind, src_relpath,
> wcroot, scratch_pool, scratch_pool));
This doesn't look right...
Bigger diff:
===
--- trunk/subversion/libsvn_wc/wc_db_update_move.c (revision 1770632)
+++ trunk/subversion/libsvn_wc/wc_db_update_move.c (revision 1770633)
@@ -2056,13 +2056,13 @@
/* Compare the tree conflict victim's copied layer (the "source") with
* the working layer, i.e. look for changes layered on top of the copy. */
SVN_ERR(get_info(_props, _checksum, _children, _kind,
src_relpath, b->src_op_depth, wcroot, scratch_pool,
scratch_pool));
SVN_ERR(get_working_info(_props, _checksum,
- _children, _kind, dst_relpath,
+ _children, _kind, src_relpath,
wcroot, scratch_pool, scratch_pool));
if (src_kind == svn_node_none
|| (dst_kind != svn_node_none && src_kind != dst_kind))
{
SVN_ERR(tc_editor_delete(nmb, dst_relpath, dst_kind, src_kind,
It looks like you are now comparing the source with the highest op-depth info
of the source...
Bert
RE: Implementing svn_ra_list for ra_serf
> -Original Message- > From: Stefan Fuhrmann [mailto:stef...@apache.org] > Sent: dinsdag 15 november 2016 12:46 > To: Subversion Development <dev@subversion.apache.org> > Subject: Implementing svn_ra_list for ra_serf > > Hi there, > > I was playing around with ra_serf to find out > what the Right Way to implement svn_ra_list > would be. But I can't decide which of the two > options would be the better one: > > * Implement it similar get_list, i.e. based upon >PROPFIND. That would require us adding the >filter patterns as additional request headers. If the PROPFIND request doesn't make the current server cache all results in ram, we could do optional server side filtering via the new header + always client side filtering here, to allow the new code to work against old servers... Bert
RE: [PATCH] Perl bindings corrupt "{DATE}" revision variable
I moved your nominations to approved with another +0.
With our Subversion binding rules one +1 of a committer for that region (yours)
and one +0 from another is enough to approve changes for the binding code.
I’m not sure about the perl rules applied around this function, but perhaps we
should just copy the string instead of changing memory that we receive as
constant. We might also have a different api function that behaves in a cleaner
way.
(The current code is better than it used to be, so my +0 stands anyway)
Bert
From: Roderich Schupp [mailto:roderich.sch...@gmail.com]
Sent: woensdag 2 november 2016 21:07
To: Daniel Shahaf <danie...@apache.org>
Cc: rai...@codingfarm.de; Subversion devel mailing list
<dev@subversion.apache.org>
Subject: Re: [PATCH] Perl bindings corrupt "{DATE}" revision variable
On Wed, Nov 2, 2016 at 8:41 PM, Daniel Shahaf <danie...@apache.org
<mailto:danie...@apache.org> > wrote:
Thanks, Roderich. Could you update the log message with an appropriate
"Verbed by"[1] clause, for contribulyzer?
Done.
I assume this should be backported, in which case, here is my +0 for
backport of the patch as committed.
Nominated for 1.8 and 1.9 incl. your vote.
Cheers, Roderich
RE: [PATCH] fix "svnadmin create" fail on x86
> -Original Message-
> From: Dengke Du [mailto:dengke...@windriver.com]
> Sent: woensdag 2 november 2016 10:22
> To: dev@subversion.apache.org
> Subject: [PATCH] fix "svnadmin create" fail on x86
>
> When run the following command on x86:
>
> svnadmin create /var/test_repo
>
> It cause segmentation fault error like the following:
>
> [16499.751837] svnadmin[21117]: segfault at 83 ip f74bf7f6
sp
> ffdd9b34 error 4 in libc-2.24.so[f7441000+1af000]
> Segmentation fault (core dumped)
>
> This is because in source code ./subversion/libsvn_fs_fs/low_level.c,
> function svn_fs_fs__unparse_footer, when:
>
> target arch:x86
> apr_off_t: 4 bytes
>
> if the "APR_OFF_T_FMT" is "lld", it still use type "apr_off_t" to pass
> data to apr, but in apr source code file apr_snprintf.c the function
> apr_vformatter meet "lld", it would use the:
>
> i_quad = va_arg(ap, apr_int64_t);
>
> It uses the apr_int64_t to deal data, it read 8 bytes, so the follow-up
> data may be error.
>
> Signed-off-by: Dengke Du <dengke...@windriver.com>
> ---
> subversion/libsvn_fs_fs/low_level.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/subversion/libsvn_fs_fs/low_level.c
> b/subversion/libsvn_fs_fs/low_level.c
> index a27bbcc..6ddbe28 100644
> --- a/subversion/libsvn_fs_fs/low_level.c
> +++ b/subversion/libsvn_fs_fs/low_level.c
> @@ -250,10 +250,10 @@ svn_fs_fs__unparse_footer(apr_off_t l2p_offset,
> {
>return svn_stringbuf_createf(result_pool,
> "%" APR_OFF_T_FMT " %s %" APR_OFF_T_FMT "
%s",
> - l2p_offset,
> + (APR_OFF_T_FMT=="lld") ?
(apr_int64_t)l2p_offset :
> l2p_offset,
This doesn't change the size of the argument...
The result of the '?:' operator is always the same type, following a set of
rules set by the C standard.
Besides that the result of the '==' operator on static strings is not
defined and commonly different between release and debug builds.
And if there is a bug in formatting apr_off_t with that macro it should
really be fixed in APR... These macros are designed to abstract away
platform specifics, we can't just fix all similar cases in our code.
Bert
RE: [PATCH] gpg-agent: search gpg-agent socket in $GNUPGHOME
> -Original Message- > From: Patrick Steinhardt [mailto:p...@pks.im] > Sent: donderdag 27 oktober 2016 11:15 > To: Subversion <dev@subversion.apache.org> > Subject: [PATCH] gpg-agent: search gpg-agent socket in $GNUPGHOME > > Hi, > > a recent thread on issues with gpg-agent lead me to take a look > at how the gpg-agent socket is located in subversion. The current > code was lacking support for $GNUPGHOME, which allows a user to > relocate his gnupg configuration directory. As setting this > environment variable would also cause S.gpg-agent to be created > inside of $GNUPGHOME, we might fail to correctly locate the file > in this case. > > Attached patch fixes the problem. Hi Patrick, Last week (in r1766327) a slightly different patch was committed to resolve this (or a similar problem). This patch was nominated for backport to 1.9.x, so test input is very welcome. Do you know if we need both patches? Bert > > [[[ > gpg_agent: search in $GNUPGHOME for gpg-agent socket > > The socket used to connect to the gpg-agent resides in the GnuPG > home directory, which is by default located at "$HOME/.gnupg". > But in fact, the home directory can be relocated by the user by > setting the environment variable GNUPGHOME, in which case the > gpg-agent socket will live at "$GNUPGHOME/S.gpg-agent". > Subversion does only search the standard home directory, though, > without evaluating $GNUPGHOME. > > Fix the issue by using the socket located at > "$GNUPGHOME/S.gpg-agent" instead of using "$HOME/.gnupg" when the > environment variable is set. > > * subversion/libsvn_subr/gpg_agent.c > (find_running_gpg_agent): evaluate $GNUPGHOME > ]]]
RE: svn commit: r1764447 - in /subversion/trunk/subversion: libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: maandag 24 oktober 2016 11:08 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1764447 - in /subversion/trunk/subversion: > libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c > > On Sun, Oct 23, 2016 at 03:31:22PM -0400, James McCoy wrote: > > On Wed, Oct 12, 2016 at 12:34:19PM -, s...@apache.org wrote: > > > Modified: subversion/trunk/subversion/libsvn_client/conflicts.c > > > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/confl ic > ts.c?rev=1764447=1764446=1764447=diff > > > > > == > > > --- subversion/trunk/subversion/libsvn_client/conflicts.c (original) > > > +++ subversion/trunk/subversion/libsvn_client/conflicts.c Wed Oct 12 > 12:34:18 2016 > > > @@ -5666,6 +5726,18 @@ diff_file_added(const char *relpath, > > > FALSE, FALSE, scratch_pool)); > > >SVN_ERR(svn_io_check_path(local_abspath, _disk_kind, > scratch_pool)); > > > > > > + if (db_kind == svn_node_file && db_kind == svn_node_file) > > > > Coverity noticed both sides of the && are the same. Should one side be > > "on_disk_kind == svn_node_file" instead? > > > > Yes indeed, it should. Thanks! I'll fix this when I find time > if it's not already been fixed by then. Be careful when committing this as an 'obvious fix'. I've seen a very similar problem in the conflict code in the past that has very explicit tests in our testsuite that verify the current behavior. It is very well possible that this is just the same code moved to a different location. If this is that specific case the problem should be fixed, but it won't be an obvious fix... more a case of careful review of all the cases that trigger this code and then updating expected results. Bert
RE: svn commit: r1765286 - in /subversion/trunk/subversion: include/svn_xml.h libsvn_subr/xml.c tests/libsvn_subr/xml-test.c
> -Original Message- > From: i...@apache.org [mailto:i...@apache.org] > Sent: maandag 17 oktober 2016 15:49 > To: comm...@subversion.apache.org > Subject: svn commit: r1765286 - in /subversion/trunk/subversion: > include/svn_xml.h libsvn_subr/xml.c tests/libsvn_subr/xml-test.c > > Author: ivan > Date: Mon Oct 17 13:49:05 2016 > New Revision: 1765286 > > URL: http://svn.apache.org/viewvc?rev=1765286=rev > Log: > Implement standard lifetime semantics for svn_xml_parser_t: the object will be > automatically freed on pool cleanup. But it still can be freed explicitly > using svn_xml_free_parser(). It's the same behavior we already have for > svn_sqlite__db_t and similar. Are you planning a new use of this api? It is currently only used by subversion/libsvn_wc/old-and-busted.c, and I don't think we should really spend time optimizing that specific usecase (reading pre 1.4 working copies) Bert
RE: svn commit: r1764536 - /subversion/branches/1.9.x/STATUS
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: donderdag 13 oktober 2016 14:00 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1764536 - /subversion/branches/1.9.x/STATUS > There's no chance of doing this in a reasonable time-frame because we > require APR-1.3 and no fix we can possibly come up with will be released > in a 1.3 patch. As long as nobody even reported the bug on APR on any apr list/group/anything, there won't be a fix... ever... Please, can we at least prioritize reporting a problem in apr and preferable fixing it there over doing workarounds that we have to maintain forever. After apr is patched I would like to see the workaround code conditionalized on being compiled against older versions of apr. Note I haven't looked at the patch in detail, but it looks like it changes a quite generic function by introducing new race conditions in certain error cases. Not something I would like to see in our code forever Bert
RE: [PATCH] Reject checkouts to existing directory
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: woensdag 12 oktober 2016 16:37 > To: Patrick Steinhardt <patrick.steinha...@elegosoft.com> > Cc: Subversion <dev@subversion.apache.org> > Subject: Re: [PATCH] Reject checkouts to existing directory > > On Wed, Oct 12, 2016 at 04:28:05PM +0200, Patrick Steinhardt wrote: > > Hi, > > > > attached is a patch to reject checkouts to already existing > > directories when `--force` is not given. This is according to > > `svn co --help`. > > > > [[ > > Reject checkout to existing paths without force > > > > * subversion/svn/checkout-cmd.c: > > - (svn_cl__checkout): Reject checkout to existing directory > > without --force > > ]] > > Nice catch. > It's odd that the actual behaviour and help string don't line up. I'm not sure if the behavior you see is actually a bug. The --force flag is already used for processing in the update editor and there are cases where I would like to turn an existing directory in a checkout, while not invoking that behavior. (I prefer conflicts, over just assuming that every file is just a modified version of the files already in the directory; the current behavior triggered by --force) I can see that you might want to have a warning when there is already a directory, but I don't think it is the right way to use the --force option for this. And then there is the feature that svn checkout is restartable when it fails after some part of the checkout (just like update)... with this patch applied that would also stop being supported. Bert
RE: New SHA1 property for nodes returned 'svn ls --xml' invocations.
This doesn’t look like some kind of update request (more like a commit). We use many different propfind requests, which usually only return the requested information as that is far more efficient than requesting all properties. I don’t see why we would need it on commit, so I’m not surprised that we don’t request it from the server just to slow the request down. In the implementation I see that we declare the sha1-checksum as live properties, so you should be able to request them if you construct an appropriate PROPFIND request. The ‘cadaver’ project build on top of the neon library might be an easy way to construct such a request. Bert From: Paul Hammant [mailto:p...@hammant.org] Sent: woensdag 12 oktober 2016 12:55 To: Subversion Development <dev@subversion.apache.org> Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations. You're right - and in the fullness of time, I'll replace all the Svn uses with their wire equivalents. If Shas were implemented at some future date, I'd be happy for them to be available via PROPFIND. I's be even more happy for them to be passed back to me in the response of a PUT. Or are you saying that shas are presently implemented but I have missed it? Cranking up the proxy server, Charles, is a great way to see what Svn is doing on the wire. Here is svnmucc pushing up a new resource to Svn (no working copy): 1. ROOT 401 OPTIONS 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo Tue Oct 11 22:58:41 EDT 2016 49 1244 Complete 2. ROOT 200 OPTIONS 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo Tue Oct 11 22:58:43 EDT 2016 28 2404 Complete 3. ROOT 200 OPTIONS 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo Tue Oct 11 22:58:43 EDT 2016 14 1470 Complete 4. ROOT 200 OPTIONS 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo Tue Oct 11 22:58:43 EDT 2016 15 2332 Complete 5. ROOT/!svn/rvr/64/TestFile 404 PROPFIND 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/!svn/rvr/64/TestFile Tue Oct 11 22:58:43 EDT 2016 14 858 Complete 6. ROOT/!svn/rvr/64/TestFile 404 PROPFIND 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/!svn/rvr/64/TestFile Tue Oct 11 22:58:43 EDT 2016 9 858 Complete 7. ROOT/!svn/rvr/64 207 PROPFIND 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/!svn/rvr/64 Tue Oct 11 22:58:43 EDT 2016 8 857 Complete 8. ROOT/!svn/me 201 POST 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/!svn/me Tue Oct 11 22:58:43 EDT 2016 179 711 Complete 9. ROOT/TestFile 404 HEAD 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/TestFile Tue Oct 11 22:58:43 EDT 2016 22 334 Complete 10. ROOT/!svn/txr/64-30/TestFile 201 PUT 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo/!svn/txr/64-30/TestFile Tue Oct 11 22:58:43 EDT 2016 86 20391 Complete 11. ROOT 200 MERGE 0.0.0.0:32768 <http://0.0.0.0:32768> /svn/testrepo Tue Oct 11 22:58:43 EDT 2016 526 1898 Complete Doing a second svnmucc operation on the same (now existing) resource, I can see via Charles that the second PROPFIND is returning 'rvr/65' for the now-existing resource (now a 207 response status). That's certainly not a sha, so I think you mistyped.
RE: [PATCH] Add '--include' and '--exclude' options to 'svnadmin dump'
> -Original Message-
> From: Sergey Raevskiy [mailto:sergey.raevs...@visualsvn.com]
> Sent: woensdag 12 oktober 2016 12:44
> To: Subversion Development <dev@subversion.apache.org>
> Subject: [PATCH] Add '--include' and '--exclude' options to 'svnadmin dump'
>
> Hi!
>
> I've attached a patch that adds '--include/--exclude' options to 'svnadmin
> dump'. These options work similarly to 'svndumpfilter include/exclude'
> but provide proper handling of 'copy from' paths.
>
> Consider the following example with svndumpfilter:
> [[
> $ svnadmin create /repo
> $ svn mkdir -m "" file:///repo/A
> $ svn copy -m "" file:///repo/A file:///repo/B
> $ svnadmin dump /repo | svndumpfilter include /B > dump
I don't see a --renumber-revs on your invocation of svndumpfilter. Did you try
these options to see if these resolve your problem (they should)
$ svndumpfilter help include
include: Filter out nodes without given prefixes from dumpstream.
usage: svndumpfilter include PATH_PREFIX...
Valid options:
--drop-empty-revs: Remove revisions emptied by filtering.
--drop-all-empty-revs: Remove all empty revisions found in dumpstream
except revision 0.
--renumber-revs : Renumber revisions left after filtering.
--skip-missing-merge-sources : Skip missing merge sources.
--targets ARG: Read additional prefixes, one per line, from
file ARG.
--preserve-revprops : Don't filter revision properties.
--quiet : Do not display filtering statistics.
--pattern: Treat the path prefixes as file glob patterns.
Bert
> ...
> Revision 0 committed as 0.
> Revision 1 committed as 1.
> svndumpfilter: E23: Invalid copy source path '/A'
> ]]
>
> The 'svnadmin dump' with proposed include/exclude options can handle this
> use
> case properly:
> [[
> $ svnadmin dump /repo --include /B > dump
> * Dumped revision 0.
> * Dumped revision 1.
> * Dumped revision 2.
> ]]
>
> The proposed options are implemented using 'svn_repos_authz_func_t' and the
> not-included copy sources are hidden by the 'svn_repos' layer.
>
> Some usage examples for the proposed options:
> [[
> $ svnadmin dump repos --include /calc > calc-dumpfile
> ...
> $ svnadmin dump repos --include /calc --include /calendar > dumpfile
> ...
> $ svnadmin dump repos --exclude /secret > dumpfile
> ...
> $ svnadmin dump repos --include /calc --exclude /calendar > dumpfile
> svnadmin: E205000: Try 'svnadmin help' for more info
> svnadmin: E205000: '--exclude' and '--include' options cannot be used
> simultaneously
>
> $ svnadmin dump repos --include /cal* --pattern > dumpfile
> ...
> ]]
>
> Log message:
>
> [[
> Add '--include' and '--exclude' options to 'svnadmin dump'.
>
> * include/svn_repos.h
> (svn_repos_dump_filter_func_t): New.
> (svn_repos_dump_fs4): Update function signature and comment.
> (svn_repos_dump_fs3): Update comment.
>
> * libsvn_repos/deprecated.c
> (svn_repos_dump_fs3): Update caller.
>
> * libsvn_repos/dump.c
> (write_revision_record): Call to svn_repos_fs_revision_proplist() (with
>AUTHZ_FUNC) instead of svn_fs_revision_proplist2() to filter revision
>properties as well as revisions. Update comment.
> (dump_filter_baton_t,
>dump_filter_authz_func): New.
> (svn_repos_dump_fs4): Initialize and pass AUTHZ_FUNC and AUTHZ_BATON
> to
>the repos layer API if FILTER_FUNC is specified by caller.
>
> * subversion/svnadmin/svnadmin.c
> (svnadmin__cmdline_options_t): Add enum values for new options.
> (options_table): Add new options.
> (cmd_table): Add new options to 'dump' subcommand.
> (svnadmin_opt_state): Add new fields to represent new options.
> (ary_prefix_match): New. Copied from svndumpfilter.
> (dump_filter_baton_t,
>dump_filter_func): New.
> (subcommand_dump): Initialize FILTER_BATON. Pass DUMP_FILTER_FUNC
> and a
>pointer to FILTER_BATON to svn_repos_dump_fs() if any filtering prefixes
>specified.
> (sub_main): Handle new options.
>
> * subversion/tests/cmdline/svnadmin_tests.py
> (dump_exclude,
>dump_exclude_copysource,
>dump_include,
>dump_not_include_copysource,
>dump_exclude_by_pattern,
>dump_include_by_pattern,
>dump_exclude_all_rev_changes,
>dump_invalid_filtering_option): New.
> (test_list): Add new tests to table.
>
> * subversion/tests/libsvn_repos/dump-load-test.c
> (test_dump_bad_props): Update caller.
>
> Patch by: sergey.raevskiy{_AT_}visualsvn.com
> ]]
RE: New SHA1 property for nodes returned 'svn ls --xml' invocations.
If you are using dav autoversioning, then why do you want to obtain the sha using 'svn’. You should be able to obtain the sha using a PROPFIND request against the server. We use that checksum from there to avoid downloading the same file multiple times in our streamlined v2 http protocol. Bert Sent from my Windows 10 phone From: Paul Hammant Sent: dinsdag 11 oktober 2016 14:09 To: Subversion Development Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations. Considering .. svn info --xml https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c I would hope for a element at root level: https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c ^/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c https://svn.apache.org/repos/asf 13f79535-47bb-0310-9956-ffa450edef68 3bc64b30547e9a0448feba6c6af48447dff2b980 ivan 2016-01-08T12:28:35.243550Z Considering .. svn ls --xml https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/ Similarly resulting in the insertion of : https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn;> ... mod_dav_svn.c 42444 3bc64b30547e9a0448feba6c6af48447dff2b980 ivan 2016-01-08T12:28:35.243550Z ... svn-ls doesn't have and entry for "." of course. It's parent has that node, and svn-ls works on directories just fine. For the entry of directory that contains mod_dav_svn.c, I'd hope for the SHA1 to be a function of the SHA1s of the files within. That's Merkle-tree style - a super important feature generally as well as specifically to my use-case. For my use-case to work, I need to have a reasonable chance of recalculating the SHA1 on the client file system without access to the remote repo, or the presence of a .svn directory. That's why I'm calling the element content-sha1. There could be a sibling element complete-sha1 which is the content-sha1 and whatever properties should be included too. I would not use that element, but properties were mentioned before. I don't have an opinion about symlinks, of experience of them with Svn. I'm unfamilar with the hat-syntax wc-centric use of svn-ls. Therefore I don't know what to say about it. I've read the ?kw=1 section of the release notes. My use case would not need keyword replacement. In fact it would need it to be off. Something about something Greek in https://svn.apache.org/repos/asf/subversion/tree/readme ? - I'm lost and need further guidance as to reading materials, please. Regards, - Paul On Tue, Oct 11, 2016 at 2:40 AM, Daniel Shahaf <danie...@apache.org> wrote: Paul Hammant wrote on Mon, Oct 10, 2016 at 22:23:25 -0400: > In that page, there is a mention of 'ModMimeUsePathInfo' that can add > properties transparently. One like it could optionally add a sha1 as a > property and that be transient like svn:log, svn:date and svn:author. > Please don't worry about implementation details at this stage. Adding a per-file attribute is easy. (It won't be like svn:log, however, because that is a revprop, as opposed to a nodeprop.) The real question is, what information you are asking to be provided. Given the standard Greek tree (see subversion/tests/README), what would be the outputs of «svn ls --xml ^/iota» and «svn ls --xml ^/A/»? Are you asking for information to be provided for plain files? For symlinks? For directories? What is the value of the new attribute in each of those cases? If it's a checksum, is it the repository-normal version or the keywords-expanded version (like ?kw=1 in mod_dav_svn, see 1.8 release notes)? Don't worry about how the information would be encoded on the wire; just about what information you would like to have on the client. Cheers, Daniel > Re the commands svn-ls and svn-info. They have an --xml flag already, and > it would be cool if there was a way of adding select properties to that. > Note that --xml and --show-item fight each other presently (and are > singular).
RE: New SHA1 property for nodes returned 'svn ls --xml' invocations.
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: maandag 26 september 2016 09:09 > To: Julian Foad <julianf...@apache.org> > Cc: Paul Hammant <p...@hammant.org>; Subversion Development > <dev@subversion.apache.org> > Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations. > What would content hashes provide that comparing node-rev id's would not? Just one example: Stability over dump-load and different subversion filesystems (bdb, fsfs, fsx and different versions of those) If we don't need it for very specific new features I think we should keep node-rev id's strictly server/repository side, as the moment we expose them we have to promise them to be stable over dump-load, which would probably imply another level of redirection. And at that point those IDs might not be the most efficient format any more. Bert
