Re: svn commit: r1888446 - /subversion/trunk/subversion/include/private/svn_task.h

On 07.04.21 06:47, Nathan Hartman wrote: On Tue, Apr 6, 2021 at 2:37 PM wrote: URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/private/svn_task.h?rev=1888446=auto [snip] A couple of really minor nits: + * During execution, a task may add further sub-tasks -

Re: Interested in making 'svn st' 10x faster?

On 06.04.21 21:14, Daniel Shahaf wrote: Stefan Fuhrmann wrote on Mon, Apr 05, 2021 at 21:17:23 +0200: +static svn_error_t *output_processed( + svn_task__t **task, + svn_cancel_func_t cancel_func, + void *cancel_baton, + apr_pool_t *result_pool, + apr_pool_t *scratch_pool

Re: Interested in making 'svn st' 10x faster?

On 06.04.21 21:00, Stefan Fuhrmann wrote: On 06.04.21 08:12, Nathan Hartman wrote: > tasks-used-optimized-wc-status.patch applied with some offsets, so is against a slightly out-of-date trunk, but applied without conflicts. But my build had many test failures: Summary of test resu

Re: Interested in making 'svn st' 10x faster?

On 06.04.21 08:12, Nathan Hartman wrote: On Mon, Apr 5, 2021 at 3:17 PM Stefan Fuhrmann wrote: See attachment (I may have used a somewhat outdated trunk). tasks-prepwork.patch refactors some utility code to make it reusable. tasks-main.patch is the new svn_task__t API, implementation

Interested in making 'svn st' 10x faster?

On 05.04.21 20:19, Nathan Hartman wrote: On Mon, Apr 5, 2021 at 6:00 AM Stefan Fuhrmann <mailto:stef...@apache.org>> wrote: Hi all, Way back in 2014, I started work on an SVN equivalent to apr_thread_pool and came back to it recently.  The key features are output and

Interested in making 'svn st' 10x faster?

Hi all, Way back in 2014, I started work on an SVN equivalent to apr_thread_pool and came back to it recently. The key features are output and callbacks happen in the same order as in sequential code, same for any svn_error_t raised, and a low-overhead single-threaded code path. Now, there is

Re: Subversion 1.12.0 up for testing/signing

On 11.04.19 16:45, Julian Foad wrote: The 1.12.0 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. Summary: +1 to release Platform Ubuntu 16.04.6 x64, Linux

Re: svn obliterate - more feasible these days?

On 01.04.19 15:13, li...@m8y.org wrote: On Fri, 29 Mar 2019, Johan Corveleyn wrote: On Fri, Mar 29, 2019 at 7:25 PM wrote: ... Now, when I run into an hg feature that I particularly find useful, I ask #svn if there's an equivalent for use at work. In this case it was hg censor which allows

Re: Subversion 1.12.0-rc1 up for testing/signing

On 04.03.19 13:34, Julian Foad wrote:> The 1.12.0-rc1 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. > > Thanks! > > - Julian > Summary: +1 to release Platform

Re: Time for new patch releases: 1.11.1, 1.10.4, 1.9.10

On 14.12.18 23:23, Julian Foad wrote: There are some important server fixes nominated for backport: SVN-4791, an issue with the DAG open_path() (for 1.9, 1.10, 1.11) SVN-4793, authz rights from inverted access selectors (for 1.10, 1.11) I'd like to cut new releases around the new year. Could

Re: [PATCH] fix use-after-free in mod_dav_svn's log_warning()

On 17.12.18 10:44, Stefan Sperling wrote: I have hit a use-after-free in mod_dav_svn while running SVN's regression tests on OpenBSD with httpd 2.4. This problem was apparently known to the author; see the comment which is removed in the diff below. In short, the request structure used as

Re: Fwd: [Daniel Shahaf: [PATCH] Re: [PATCH] A test for "Can't get entries" error]

On 21.11.18 16:00, Daniel Shahaf wrote: Good morning Stefan, Forwarding from dev@. tl;dr: False positive SVN_ERR_FS_NOT_DIRECTORY error, with test¹, workaround, analysis, and patch. The error doesn't happen with caches disabled so I thought you might be interested. Cheers, Daniel ¹ The

Re: Subversion 1.11.0-rc1 up for testing/signing

On 13.09.2018 14:13, Julian Foad wrote: The 1.11.0-rc1 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. Thanks! Since I don't know if & when I will find time to address

Re: authz changes between 1.9 and 1.10

Most of these issues have already been addressed by Brane, but as he wished for my input, here it is. These are the guiding principles for the 1.10 authz design: (1) ACLs are only evaluated on a per-user bases; ACLs that     don't mention this user (or any of their groups)  are ignored.    

On my hiatus

Hey there, due to 80% desirable changes in my personal life, I suddenly found myself falling off the Subversion diskworld. Sorry for the sudden loss of communication, it was never intentional. From where I am now, it seems that I will stay in Europe. My hope is to get back to regular

Re: Subversion1.10.0-rc2 up for testing/signing

On 29.03.2018 15:17, Julian Foad wrote: The 1.10.0-rc2 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. Thanks! Summary:   +1 to release Platform   Ubuntu 16.04.4 x64,

Re: Warnings from the bindings

On 30.03.2018 00:27, Philip Martin wrote: Philip Martin writes: +1 to release The swig-pl tests produce warnings for: Warning: unable to close filehandle $out_fh properly: Bad file descriptor at

Re: Subversion1.10.0-rc1 up for testing/signing

On 19.02.2018 17:16, Julian Foad wrote: The 1.10.0-rc1 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. Thanks! Summary: +1 to release Platform Ubuntu 16.04.4 x64,

Making build bots happy

As per Community Guide, I approved two subversion/test fixes with < 3 "+1" votes in r1820444 and r1820445, respectively. That should fix the build bot failures for 1.9 and 1.10 that we saw for some time now. -- Stefan^2.

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

On 28.12.2017 19:17, Stefan Fuhrmann wrote: On 25.12.2017 14:20, Stefan Sperling wrote: On Mon, Dec 25, 2017 at 12:21:46PM +0100, Stefan Fuhrmann wrote: So, this is the result. It also covers the changes skipped by release.py (first block of 5 entries). I will try to reformulate & g

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

On 25.12.2017 14:20, Stefan Sperling wrote: On Mon, Dec 25, 2017 at 12:21:46PM +0100, Stefan Fuhrmann wrote: So, this is the result. It also covers the changes skipped by release.py (first block of 5 entries). I will try to reformulate & group the list and then commit them to CHA

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

On 24.12.2017 09:39, Stefan Fuhrmann wrote: On 23.12.2017 14:30, Johan Corveleyn wrote: I'm afk for a couple of days so can't try it myself now, but     release.py write-changelog --include-unlabeled-summaries branches/1.10.x tags/1.10.0-alpha3 might provide a good starting point. I'm

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

On 23.12.2017 14:30, Johan Corveleyn wrote: I'm afk for a couple of days so can't try it myself now, but     release.py write-changelog --include-unlabeled-summaries branches/1.10.x tags/1.10.0-alpha3 might provide a good starting point. I'm giving it a try right now. It starts with 162

Re: list --search matching and Windows *-expansion

On 21.12.2017 14:50, Stefan Fuhrmann wrote: On 19.12.2017 11:06, Stefan Sperling wrote: On Mon, Dec 18, 2017 at 08:59:08PM +, Julian Foad wrote: Stefan Sperling wrote: On Mon, Dec 18, 2017 at 06:01:52PM +, Daniel Shahaf wrote: Branko Čibej wrote on Mon, 18 Dec 2017 16:24 +0100

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

svn_dirent_t.size API inconsistency

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

Re: list --search matching and Windows *-expansion

On 18.12.2017 15:20, Johan Corveleyn wrote: On Tue, Dec 5, 2017 at 10:12 PM, Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: Stefan Fuhrmann <stef...@apache.org> writes: There seems to be little that could be done here (suggestions welcome). The problem is that the aster

Re: Supporting precooked fsfs v7 and v1-v3 in the test suite (was: Re: svn commit: r1813898 [...])

On 27.11.2017 12:41, Evgeny Kotkov wrote: [Changing subject, as apparently the test failures are not connected to the discussed fix for the rep sharing and issues #4623, #4700] Stefan Fuhrmann <stef...@apache.org> writes: Test expectations may need to be adapted. With v7 repos (see r1

Re: Potential regression: high server-side memory consumption during import (was: Subversion 1.10 RC1?)

On 05.12.2017 22:05, Evgeny Kotkov wrote: Julian Foad writes: After any issues raised in this discussion are resolved, we feel we should go ahead and produce RC1 as soon as possible. I think that I am seeing a 1.10 regression in terms of httpd's memory usage during

Re: Ideas for tracking Authz changes in a repo

On 29.11.2017 18:40, Paul Hammant wrote: Thanks for this Marc. I'll go ahead and play with it to learn it capabilities and (hopefully few) snags. In 1.10 and for svn:// since 1.9, in-repository authz can be a lot faster than file-based authz. The reason is that repositories provide O(1)

Re: Subversion 1.10 RC1?

On 22.11.2017 14:21, Stefan Fuhrmann wrote: On 22.11.2017 11:53, Julian Foad wrote: At the hackathon today we (me, Stefan Hett, Bert, Johan) have been talking about how to progress 1.10. We think all the features and changes are safe to release and are not going to get more testing until

Re: Subversion 1.10 RC1?

On 22.11.2017 15:48, Evgeny Kotkov wrote: The other two features that I remember, are: * improved authz with support for wildcards * server-side search with `svn ls --search` Speaking of the `ls --search`, I think that there is an issue with the command-line parsing. Based on what I see, the

Re: svn commit: r1813898 - in /subversion/trunk/subversion: libsvn_fs_fs/transaction.c libsvn_repos/reporter.c tests/cmdline/basic_tests.py tests/cmdline/svnadmin_tests.py

On 25.11.2017 21:27, Evgeny Kotkov wrote: Stefan Fuhrmann <stef...@apache.org> writes: An alternative approach that might be worth considering here would be: (1) Extend the on-disk format and allow representation strings without SHA1, but with the uniquifier, somethin

Re: svn commit: r1813898 - in /subversion/trunk/subversion: libsvn_fs_fs/transaction.c libsvn_repos/reporter.c tests/cmdline/basic_tests.py tests/cmdline/svnadmin_tests.py

On 22.11.2017 22:08, Evgeny Kotkov wrote: Stefan Sperling writes: However, if rep-sharing is enabled, svn_fs_props_changed() does not work as advertised because properties do not carry a SHA1 checksum with a "uniquifier" which identifies the transaction they were created in.

Re: Subversion 1.10 RC1?

On 22.11.2017 11:53, Julian Foad wrote: At the hackathon today we (me, Stefan Hett, Bert, Johan) have been talking about how to progress 1.10. We think all the features and changes are safe to release and are not going to get more testing until we produce a "release candidate". (For example,

Re: [RFC] Upgrade to C'90 as our minimum C language

On 24.09.2017 23:03, Branko Čibej wrote: On 24.09.2017 22:05, Daniel Shahaf wrote: Branko Čibej wrote on Sun, 24 Sep 2017 21:56 +0200: What /I/ don't understand is why we're even having a discussion about using // comments. Is it really that hard to type two extra chars per comment,

Re: Repository load failing on 1.9.x

On 11.09.2017 13:52, Bert Huijben wrote: 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

Re: OS X build slave failing

On 04.09.2017 12:14, Stefan Hett wrote: On 9/3/2017 5:03 PM, Stefan Fuhrmann wrote: On 02.09.2017 13:54, Branko Čibej wrote: The OSX build slave is failing on a couple of the conflict resolver tests over ra_svn. Can someone please take the time to figure it out? Otherwise my maintaining

Re: svn commit: r1807056 - in /subversion/trunk/subversion: include/private/svn_utf_private.h libsvn_client/list.c libsvn_repos/list.c libsvn_subr/utf8proc.c

On 02.09.2017 18:26, Branko Čibej wrote: On 02.09.2017 18:06, Stefan Fuhrmann wrote: On 02.09.2017 17:17, Branko Čibej wrote: On 02.09.2017 17:12, stef...@apache.org wrote: +svn_boolean_t +svn_utf__fuzzy_glob_match(const char *str, + const apr_array_header_t

Re: OS X build slave failing

On 02.09.2017 13:54, Branko Čibej wrote: The OSX build slave is failing on a couple of the conflict resolver tests over ra_svn. Can someone please take the time to figure it out? Otherwise my maintaining the build slave makes no sense ... r1807154 should fix these. -- Stefan^2.

Re: svn ls --search/pattern/glob/case-insensitive

On 01.09.2017 17:24, Julian Foad wrote: Stefan Sperling wrote: On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote: The above behaviour looks good to me. However, as you already pointed out, matching child path components seems to be impossible at present: $ svn ls -r3 --pattern

Re: svn ls --search/pattern/glob/case-insensitive

On 01.09.2017 15:31, Branko Čibej wrote: On 01.09.2017 06:36, Stefan Fuhrmann wrote: On 29.08.2017 14:04, Branko Čibej wrote: On 29.08.2017 13:28, Stefan Sperling wrote: On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote: How would you implement the case-insensitive

Re: svn commit: r1807056 - in /subversion/trunk/subversion: include/private/svn_utf_private.h libsvn_client/list.c libsvn_repos/list.c libsvn_subr/utf8proc.c

On 02.09.2017 17:17, Branko Čibej wrote: On 02.09.2017 17:12, stef...@apache.org wrote: +svn_boolean_t +svn_utf__fuzzy_glob_match(const char *str, + const apr_array_header_t *patterns, + svn_membuf_t *buf) +{ + const char *normalized; +

Re: svn ls --search/pattern/glob/case-insensitive

On 01.09.2017 13:30, Stefan Sperling wrote: On Fri, Sep 01, 2017 at 06:36:46AM +0200, Stefan Fuhrmann wrote: Because I think that strict glob-like patterns need to be supported as well, I suggest to have two options: --search does a fuzzy search just like we use it in other commands

Re: svn ls --search/pattern/glob/case-insensitive

On 29.08.2017 14:04, Branko Čibej wrote: On 29.08.2017 13:28, Stefan Sperling wrote: On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote: How would you implement the case-insensitive comparison on the server side consistent with the client-side locals? As far as I can tell

Re: svn ls --search/pattern/glob/case-insensitive [was: svn commit: r1806548 ...]

On 29.08.2017 12:46, Julian Foad wrote: Evgeny Kotkov wrote: Bert Huijben writes: 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

Re: 'svn list --search' feature complete?

On 29.08.2017 12:22, Johan Corveleyn wrote: On Tue, Aug 29, 2017 at 12:08 PM, Stefan Fuhrmann <stef...@apache.org> wrote: On 18.08.2017 13:36, Johan Corveleyn wrote: On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann <stef...@apache.org> wrote: On 24.01.2017 12:20, Stefan Sp

Re: 'svn list --search' feature complete?

On 18.08.2017 13:36, Johan Corveleyn wrote: On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann <stef...@apache.org> wrote: On 24.01.2017 12:20, Stefan Sperling wrote: ... I would like to get an 1.10.0 alpha1 released in February. Unless I hear objections I will start rolling this alpha r

Re: 1.10.0-alpha3 up for signing/testing

On 19.07.2017 17:00, Daniel Shahaf wrote: The 1.10.0-alpha3 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. Thanks! Summary: +1 to release Platform Ubuntu

Re: Expected speed of commit over HTTP?

On 07.07.2017 01:10, Paul Hammant wrote: With autorevision set to 'on' and curl: Reverence speed for boot drive to USB3 spinning platter 4TB thing: paul@paul-HiBox:~$ time cp /home/paul/clientDir/seven /media/paul/sg4t/sevenb real0m1.539s That isn't exactly accurate - you write

Re: svn commit: r1801108 - in /subversion/trunk/subversion/bindings/javahl/native: Array.cpp CreateJ.cpp Iterator.cpp OperationContext.cpp RemoteSession.cpp RevisionRangeList.cpp

On 06.07.2017 23:11, Philip Martin wrote: Philip Martin writes: I've upgraded my JDK and it produced all these warnings. Excellent to see these warnings being addressed! There is a second class of warnings of the form: WARNING: JNI local refs: 57, exceeds

Re: 1.8.18 release available for testing/signing

On 03.07.2017 12:55, Stefan Sperling wrote: 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! Summary: +1 to release (despite binding issues similar to 1.9.6 - see below)

Re: 1.9.6 up for signing/testing

On 30.06.2017 15:05, Daniel Shahaf wrote: 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

Re: 1.8.x vote urgently needed!

On 30.06.2017 16:38, Daniel Shahaf wrote: Stefan Sperling wrote on Fri, 30 Jun 2017 16:10 +0200: We need an additional vote now in order to roll a 1.8 tarball today. Can anyone help? * r1785737, r1785738, r1785734, r1786447, r1785754, r1786445, r1786446, r1786515, r1794611, r1800387

Re: heap-use-after-free in object_ref_cleanup

On 29.05.2017 05:45, Orivej Desh wrote: * Stefan Fuhrmann <stef...@apache.org> [2017-05-28] The callstacks suggests that this is a pool cleanup race. Please try the attached patch and report the results. Thanks! With this patch subversion from trunk no longer crashes, and subversion

Re: heap-use-after-free in object_ref_cleanup

On 23.05.2017 10:20, Orivej Desh wrote: Hello, I noticed in dmesg that in my repository svnserve occasionally crashes. This happens at exit, so it is not visible to end users. I captured a few sessions at the svn protocol level that resulted in a crash; client commands are quite different in

Re: svn commit: r1796399 - in /subversion/trunk/subversion: libsvn_fs_x/batch_fsync.c libsvn_ra/ra_loader.c libsvn_repos/dump.c libsvn_subr/pool.c svnadmin/svnadmin.c

Oops.. sorry! A test script ran commit in the wrong folder :/ Thanks for notifying! -- Stefan^2. On 27.05.2017 16:24, Stefan Sperling wrote: On Sat, May 27, 2017 at 02:14:56PM -, stef...@apache.org wrote: Author: stefan2 Date: Sat May 27 14:14:55 2017 New Revision: 1796399 URL:

r1794536 broke 1.9.x-strict-rep-sharing

Probably some subtle overlook in the conflict resolution. Shouldn't be too hard to find & fix. I'll do that tomorrow. -- Stefan^2.

Re: ra_svn vwrite_tuple() optional elements robustness

On 21.05.2017 20:28, Daniel Shahaf wrote: Stefan Fuhrmann wrote on Sun, 21 May 2017 20:09 +0200: On 15.11.2016 00:43, Daniel Shahaf wrote: Stefan Fuhrmann wrote on Mon, Nov 14, 2016 at 12:50:51 +0100: On 06.11.2016 02:21, Daniel Shahaf wrote: During the r1767197 thread, I noticed

Re: svn commit: r1769532 - in /subversion/trunk/subversion: include/private/svn_log.h libsvn_fs_x/fs.h libsvn_subr/log.c

On 14.11.2016 12:21, Bert Huijben wrote: -Original Message- From: stef...@apache.org [mailto:stef...@apache.org] Sent: zondag 13 november 2016 19:20 To: comm...@subversion.apache.org Subject: svn commit: r1769532 - in /subversion/trunk/subversion: include/private/svn_log.h

Re: svn commit: r1764676 - /subversion/trunk/subversion/libsvn_fs_fs/pack.c

On 13.10.2016 16:36, Ivan Zhakov wrote: On 13 October 2016 at 15:49, wrote: Author: stefan2 Date: Thu Oct 13 13:49:47 2016 New Revision: 1764676 URL: http://svn.apache.org/viewvc?rev=1764676=rev Log: Make the FSFS pack no longer depend on a working file trunc() operation.

Re: Subversion AuthZ Wildcards

On 27.02.2017 17:05, Julian Foad wrote: Doug Robinson wrote: Folks: "Julian said Stefan said this could be useful." :-) I really hope it is. Best wishes and thank you all! Thank you very much, Doug! Same here. Sadly, my talk wasn't admitted at ApacheCON (it seems very few were outside

Re: why svn object pools? (Re: svn commit: r1782614 - /subversion/trunk/subversion/libsvn_repos/authz.c)

On 11.02.2017 17:18, Stefan Sperling wrote: On Sat, Feb 11, 2017 at 04:07:07PM -, s...@apache.org wrote: Author: stsp Date: Sat Feb 11 16:07:06 2017 New Revision: 1782614 URL: http://svn.apache.org/viewvc?rev=1782614=rev Log: Fix a crash during init in libsvn_repos with pool debugging

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

On 16.05.2017 15:10, Jacek Materna wrote: On Sun, May 14, 2017 at 1:59 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de> wrote: On 09.05.2017 20:43, Stefan Sperling wrote: On Mon, May 08, 2017 at 10:46:39AM +0200, Jacek Materna wrote: Team, I wanted to start a discussion around t

Re: [PATCH] Re: verify_as_revision_before_current_plus_plus() on a production repo?

On 16.03.2017 12:50, Julian Foad wrote: Daniel Shahaf wrote: should our policy be to provide administrative choice? A knob sounds good to me [...] And Bert said "+1" on IRC too. The attached patch is a basic implementation. The fsfs.conf option is spelled [debug]

Re: Unbuddied issue workflow

On 16.05.2017 17:59, Stefan Sperling wrote: On Tue, May 16, 2017 at 03:49:32PM +, Daniel Shahaf wrote: We could probably change the "File an issue" jira workflow to prevent people from filing unbuddied issues, and instead, having jira tell them to email users@. I'm thinking of interjecting

Re: bug in svnadmin verify -M argument processing

On 15.03.2017 01:30, Stefan Sperling wrote: If the -M option sees something that does not look like a number, we get a NULL cache but this isn't handled properly. svnadmin verify should probably errror out which is easy to fix. But this may suggest there is a problem somewhere inside the

Re: [SVN-4677] svn up fails after a file is replaced by a directory

On 01.05.2017 20:48, Orivej Desh wrote: Stefan, could you please consider this bug report? Orivej, Thanks for the detailed bug report! It made the issue easy to track down and fix (r1795116). May or may not make it into 1.9.6. -- Stefan^2. * Johan Corveleyn

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

On 09.05.2017 20:43, Stefan Sperling wrote: On Mon, May 08, 2017 at 10:46:39AM +0200, Jacek Materna wrote: Team, I wanted to start a discussion around the FAQ (and 1.10 rls. notes) as it pertains to the SHA-1 issue affecting all versions of SVN RE: "Continue the 1.10 alphas?" thread. I have

Re: stricter text conflicts in 1.10

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

Re: ra_serf pristine-downloading-optimisation should use capability negotiation

On 10.05.2017 01:10, Johan Corveleyn wrote: Bringing this point from irc to dev@, so it doesn't get lost: In the context of the recent SHA1-collision problems, and the viability of ra_serf's pristine-downloading-optimisation (which uses SHA-1), Brane suggested on irc: RA optimization "should"

Re: [PATCH] reject SHA1 collisions

On 09.05.2017 15:25, Stefan Sperling wrote: On Tue, May 09, 2017 at 01:39:49PM +0200, Stefan Sperling wrote: On Tue, May 09, 2017 at 11:38:51AM +0200, Stefan Sperling wrote: On Tue, Apr 18, 2017 at 12:54:20AM +, Daniel Shahaf wrote: % svnadmin load r2 < dump <<< Started new transaction,

Re: Inconsistencies in FSFS cache-* options

On 16.03.2017 15:08, Julian Foad wrote: Stefan2 et al.: Nodeprops caching is new in 1.10. This caused me to have a look at the code for enabling it, and I noticed the following in FSFS (and the same in FSX). In subversion/libsvn_fs_fs/caching.c@1787000, around line 100: > /* don't cache

Re: API review for 1.10 -- svn_ra_list()

On 16.03.2017 16:32, Julian Foad wrote: Stefan2 et al.: In svn_ra.h around line 1132, two new-in-1.10 additions, with several issues with their doc strings. svn_ra_dirent_receiver_t: bad @a/@c references: svn_repos_list, path/rel_path, path_info_only svn_ra_list(): bad @a/@c

Re: svn commit: r1786446 - /subversion/trunk/subversion/libsvn_fs_fs/transaction.c

On 20.03.2017 17:22, Bert Huijben wrote: -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

Re: wildcard authz docs question

On 15.03.2017 10:55, Daniel Shahaf wrote: >From the 1.10 draft release notes: All wildcards apply to full path segments only, i.e. * never matches /, except for the case where /**/ matches zero or more path segments. For example, /*/**/* will match any path which contains at least 2 segments

Re: Progress on SHA-1 fixes in patch releases?

On 30.03.2017 21:38, Daniel Shahaf wrote: Let's use jira or moinmoin to track all the different issues that need looking into? I count at least fsfs, fsx, svnadmin load, libsvn_wc, and zhakov's change that Bert mentioned. What is the problem with 'svnadmin load'? It uses SHA1 and MD5 to

Re: svn commit: r1791463 - /subversion/branches/1.9.x/STATUS

On 15.04.2017 10:09, Stefan Sperling wrote: On Sat, Apr 15, 2017 at 07:47:28AM -, stef...@apache.org wrote: Author: stefan2 Date: Sat Apr 15 07:47:28 2017 New Revision: 1791463 URL: http://svn.apache.org/viewvc?rev=1791463=rev Log: * STATUS: Vote for and approve r1781655 (rep-cache open

Re: svn commit: r1785734 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

On 06.03.2017 21:53, Daniel Shahaf wrote: stef...@apache.org wrote on Mon, Mar 06, 2017 at 19:05:45 -: +static svn_error_t * +test_rep_sharing_strict_content_check(const svn_test_opts_t *opts, + apr_pool_t *pool) +{ + /* Bail (with success) on

Re: svn commit: r1785754 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_fs_fs/cached_data.c libsvn_fs_fs/cached_data.h libsvn_fs_fs/transaction.c tests/libsvn_fs/fs-test.c

On 06.03.2017 21:56, Daniel Shahaf wrote: stef...@apache.org wrote on Mon, Mar 06, 2017 at 19:53:55 -: Author: stefan2 Date: Mon Mar 6 19:53:55 2017 New Revision: 1785754 URL: http://svn.apache.org/viewvc?rev=1785754=rev Log: Make FSFS consistency no longer depend on hash algorithms.

Re: 1.10.0-alpha2 is up for signing

On 06.03.2017 10:38, Stefan Sperling wrote: On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote: The new 1.10.1-alpha2 release is up for signing. The proposed 1.10.0-alpha1 release had a compilation problem on Windows. The alpha2 release should fix this problem. It is based on

Fast alternative hash (was: Files with identical SHA1 breaks the repo)

On 01.03.2017 05:17, Greg Stein wrote: I really like this idea. And we could take a copy of APR's sha1 code, and rejigger it to perform *both* hashes during the same scan of the raw bytes. I would expect the time taken to extend by (say) 1.1X rather than a full 2X. The inner loop might cost

Re: [PATCH] use SHA-2 family hash for releases

On 24.02.2017 06:26, Daniel Shahaf wrote: Andreas Stieger wrote on Thu, Feb 23, 2017 at 21:08:43 +0100: +++ tools/dist/release.py (working copy) @@ -537,9 +537,9 @@ def roll_tarballs(args): shutil.move(filename, get_deploydir(args.base_dir)) filename =

Zero spare cycles ATM

Hi all, I've noticed the threads I want to respond to are piling up. Right now, I'm completely inundated by $dayjob. I should be back to the list in about 2 weeks and post my comments if I feel those threads still need my input. -- Stefan^2.

Re: svn commit: r1780810 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs/deprecated.c libsvn_fs/fs-loader.c libsvn_fs/fs-loader.h libsvn_fs_base/tree.c libsvn_fs_fs/tree.c libsvn_fs_x/tr

On 29.01.2017 16:45, Branko Čibej wrote: On 29.01.2017 16:35, stef...@apache.org wrote: +/** + * Same as svn_fs_get_mergeinfo3(), but all mergeinfo is being collected + * and returned in @a *catalog. It will never be @c NULL, but may be empty. + * * @since New in 1.8. + * + * @deprecated

Re: Low level of activity

On 04.02.2017 17:53, Daniel Shahaf wrote: I wrote the following in a thread on private@, but the issue need not be discussed confidentially: Daniel Shahaf wrote on Fri, Feb 03, 2017 at 18:05:27 +: I've noticed that some threads don't happen. Examples: - stefan2 solicited reviews of his

Re: rep_read_contents() edge case checksum error, FSFS f7

On 30.01.2017 20:09, Stefan Fuhrmann wrote: On 29.01.2017 22:27, Julian Foad wrote: Stefan, is this an edge case bug? rep_read_contents() in libsvn_fs_fs/cached_data.c@1780363 is quoted below. rep_read_contents() potentially reads one or more times from the fulltext cache and then finds

Re: ra-test.exe deadlock condition

On 31.01.2017 10:09, Stefan wrote: Hi, I've been looking at the cause of a deadlock when running ra-test.exe with -fs-type=fsx (trunk version). The most important findings are summed up here atm [1]. The issue was discussed with brane and danielsh on IRC (thanks for your time, once again).

Re: rep_read_contents() edge case checksum error, FSFS f7

On 29.01.2017 22:27, Julian Foad wrote: Stefan, is this an edge case bug? rep_read_contents() in libsvn_fs_fs/cached_data.c@1780363 is quoted below. rep_read_contents() potentially reads one or more times from the fulltext cache and then finds the fulltext cache is no longer available. I

Re: conflict resolver status update (roll 1.10.0 alpha 1?)

On 24.01.2017 12:20, Stefan Sperling wrote: Hi, Another update on the new conflict resolver: We have 36 conflict resolver tests, all of which PASS. I have updated the wiki page about conflict tests accordingly: https://wiki.apache.org/subversion/TreeConflictTests The 36 tests we have still do

Re: [OT] Going to FOSDEM

On 28.01.2017 15:29, Julian Foad wrote: I'm going to FOSDEM next weekend, woo-hoo! https://fosdem.org/2017/ Any other svn hackers going? Hope to see you there if so. The ASF emailed a couple of weeks ago indicating the ASF would have a stand and a few ASF people will be attending, although

Re: svn commit: r1779617 - /subversion/trunk/subversion/libsvn_ra_svn/client.c

On 20.01.2017 15:04, Bert Huijben wrote: -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

Re: mod_authz_svn and caching

On 14.11.2016 10:34, Stefan Fuhrmann wrote: On 11.11.2016 01:01, Branko Čibej wrote: On 06.11.2016 13:47, Stefan Fuhrmann wrote: On 05.11.2016 17:51, Hans van Kranenburg wrote: I don't see noticable performance issues at all while reparsing the little files every time right now (how big

Re: #4667, Merge uses large amount of memory

On 09.01.2017 10:59, Julian Foad wrote: Stefan Fuhrmann wrote: Trying to remove obsolete entries ... [...] keep POTENTIAL branch /branches/___/242794/Data/H___/S___/T___ Memory fault Looks like a segfault in disguise. Could you run that in a debugger and see where it crashes (stack)? I

Re: #4667, Merge uses large amount of memory

On 06.01.2017 13:26, Julian Foad wrote: I wrote: "svn-mergeinfo-normalizer" fails to execute in the available RAM. But looking closer, it says "Memory fault" which may indicate some other kind of failure rather than not enough memory. Stefan Fuhrmann wrote: If the

Re: #4667, Merge uses large amount of memory

On 04.01.2017 16:02, Julian Foad wrote: Stefan Fuhrmann wrote: Julian Foad wrote: https://issues.apache.org/jira/browse/SVN-4667 [...] The branches involved have subtree mergeinfo on over 3500 files, each referring to about 350 branches on average, and just over 1 revision range on average

Re: #4667, Merge uses large amount of memory

On 03.01.2017 15:58, Julian Foad wrote: https://issues.apache.org/jira/browse/SVN-4667 I am currently contracting for WANdisco to help a customer whose merge is using excessive RAM. The merge will not complete with 4 GB RAM and will complete with 5 GB RAM available. The branches involved have

Authzperf coming to trunk soon

Hi all, I think the new authz implementation is ready to be merged to /trunk and plan to merge it on 1/1/17. Until then, only two discrepancies with /trunk behavior need to be fixed (registry support and one precedence issue), see also BRANCH-README. I already have the code available and only

Re: 1.9.5 up for signing/testing

On 21.11.2016 16:30, Evgeny Kotkov wrote: 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

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

  1   2   3   4   5   6   7   8   9   10   >