Re: Bug report: Regression SVN Client, SSL, Serf 1.3.9-3, SSLVerifyClient require

Daniel Shahaf writes: > Subversion uses Serf, which uses OpenSSL, which talks to an SSL implementation > on the server. The root cause of the error is known to the SSL implementation > on the server (that's why you see it in the error log). It's not obvious that > OpenSSL on the client side

Re: Bug report: Regression SVN Client, SSL, Serf 1.3.9-3, SSLVerifyClient require

Folker Schamel writes: > After upgrading, Subversion SSL connections with "SSLVerifyClient > require" seem to be broken. > > Broken: SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient require" > Works:  SVN Client 1.9.5, Serf 1.3.9-3, Server "SSLVerifyClient off" > Works:  SVN Client 1.9.5,

authz pool usage

One thing I noticed in the new authz code is: typedef struct ctor_baton_t { ... /* The parser's scratch pool. This may not be the same pool as passed to the constructor callbacks, that is supposed to be an iteration pool maintained by the generic parser. N.B.: The result pool

Re: authz changes between 1.9 and 1.10

Daniel Shahaf writes: > Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200: >> It's definitely better to have consistent behaviour across all rule >> types. > > +1 I like the idea of achieving consistency by making the duplicate entries into an error: it changes the behaviour of 1.10 but anyone

Re: authz changes between 1.9 and 1.10

Branko Čibej writes: > It's worth working on a fix, IMO. My suggestion would be: > > * Keep the single-rule behaviour as it turned up in 1.10, just > document it. It's necessary for glob rules and making an exception > for "old-style" rules will limit the ways we can improve the authz

Re: ra_serf not storing client cert creds

Daniel Shahaf writes: > Not opposed to reinstating, but curious how come this regression hasn't > been noticed until now. It has been just over five years since we > dropped ra_neon (in 1.8.0). Did some distro only recently upgrade from > 1.7 to 1.9 or something? I suspect it wasn't reported

ra_serf not storing client cert creds

I've noticed a feature that seems to be have been lost when we switched from neon to serf: serf doesn't store the client cert creds. There are two bits of data, the path to the pkcs12 file and the password for the private key. The ra_serf library will prompt for these, if

Re: authz changes between 1.9 and 1.10

Branko Čibej writes: > On 20.07.2018 14:59, Philip Martin wrote: >> In 1.9 it was possible to repeat, or reopen, a section: > > It's an intentional change that is documented in the design wiki page. And only there, it didn't make the release notes. >> In 1.9 any repea

authz changes between 1.9 and 1.10

In 1.9 it was possible to repeat, or reopen, a section: [/some/path] user = r [/some/path] otheruser = rw This was equivalent to a single section: [/some/path] user = r otheruser = rw In 1.10 this is rejected by the parser and cannot be used. Is this a bug in 1.10 or an

Re: svn commit: r1834612 - in /subversion/branches/1.10.x-issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py

Julian Foad writes: > Philip, can you help clarify this? >> >> It's not clear to me from the added paragraph whether the restriction >> "only access the context from a thread at a time" is imposed by the >> library implementation or by the way API consumers' code is typically >> structured.

Re: Next stable releases

Julian Foad writes: > Julian Foad wrote: >> Philip Martin wrote on 2018-06-05: >> > It's time to consider 1.9.8 and 1.10.1. >> >> I can prepare these releases. Please nominate/review/vote on backports. > > I plan to roll these releases on Thursday. One

Re: [PATCH] Fix segfault when gnome keyring lookup fails

Jan Palus writes: > On 12.07.2018 15:08, Daniel Shahaf wrote: >> Thanks for the patch; however, I don't think that's the correct fix. > > To be honest I wasn't sure of that either but on the other hand I thought that > having initialized state won't hurt. > >> Does the following patch fix the

Re: svn commit: r1834612 - in /subversion/branches/1.10.x-issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py

Philip Martin writes: > "Bert Huijben" writes: > >> 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. &

Re: svn commit: r1834612 - in /subversion/branches/1.10.x-issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py

"Bert Huijben" writes: > 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. Changing the client config like this doesn't affect the wc config as

Re: svn commit: r1834612 - in /subversion/branches/1.10.x-issue4758/subversion: libsvn_client/shelve.c tests/cmdline/shelve_tests.py

julianf...@apache.org writes: > 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". > + /* Ensure we use

Re: shelf-tests failure on macOS

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

Re: shelf-tests failure on macOS

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

Re: JavaHL crash on macOS 10.13.5

Thomas Singer writes: > For adding/committing an empty file he is getting: > >> $ touch testfile.txt >> $ svn add testfile.txt A testfile.txt >> $ svn commit -m "commit test" testfile.txt Adding testfile.txt >> Transmitting file data .svn: E175002: Commit failed (details follow):

Re: handling of reparse points

Branko Čibej writes: >> We do use that flag, but — just like cross-device copies on Unix — the >> move is no longer atomic, which could break the working copy quite badly. > > I mean cross-device moves, of course, not copies. svn_io_file_move() is our wrapper that is intended to make it work:

Re: JavaHL crash on macOS 10.13.5

Thomas Singer writes: >> Thread 44 Crashed:: Java: WorkerThread-3 >> 0 libsystem_kernel.dylib 0x7fff696a0b6e __pthread_kill + 10 >> 1 libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333 >> 2 libsystem_c.dylib0x7fff695fc1ae abort + 127 >>

Next stable releases

It's time to consider 1.9.8 and 1.10.1. 1.9.7 has issue 4722, the spurious SHA1 checksum fail during commit: https://issues.apache.org/jira/projects/SVN/issues/SVN-4722 This has been reported more than once on users and is a regression from earlier 1.9.x. 1.10.0 has issue 4741, an authz group

Re: handling of reparse points

Stefan Küng writes: > Index: subversion/libsvn_subr/io.c > === > --- subversion/libsvn_subr/io.c (revision 1831874) > +++ subversion/libsvn_subr/io.c (working copy) > @@ -342,8 +342,11 @@ >/* Not using svn_io_stat()

Re: Group contain problem in authz

黄磊 writes: > We meet a problem while upgrade the SVN server from 1.9 to 1.10. In > the file 'authz', it seems not support for group to contain other > group. > > I can give a simple example. > In the 'authz' file: > > [groups] > GuserA = userA > GuserB = userB > GroupA

Re: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

Joe Orton writes: > I thought about that, but the SVN buildsystem is building & installing > them like libraries not like DSOs (which should be linked with libtool's > -module argument and not installed directly in $libdir), I suspect that is accidental. The RA/FS option

Re: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

Philip Martin <phi...@codematters.co.uk> writes: >> Fixes libsvn_auth_gnome_keyring.pc when configured with libsecret, and >> make dependencies private. > > Looks OK to me. Perhaps we should delete the .pc files for gnome/kwallet auth libraries. The corresponding libr

Re: How to disable lz4 support when library is installed in system?

Daniel Shahaf writes: > Shall we backport it, so '--without-lz4' produces an error as intended? Nominated in STATUS. -- Philip

Re: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

Joe Orton writes: > libsvn_auth_gnome_keyring.pc is wrong in 1.10.0; when built against > libsecret it still references the gnome-keyring library. > > ... > Requires: apr-1 gnome-keyring-1 > Requires.private: libsvn_subr > > The dep should also be private; fix attached OK?

Re: svn commit: r1829344 - in /subversion/trunk/build/ac-macros: lz4.m4 utf8proc.m4

Johan Corveleyn writes: > Maybe we could add an extra hint to the error message along the lines > of "Maybe you want --with-lz4=internal"? To help self-serviceness and > avoid mails to the users list ... I don't think that is a good recommendation. Internal libraries should

Re: How to disable lz4 support when library is installed in system?

Daniel Shahaf writes: > In principle, if svn were built without lz4 (which isn't supposed to be > allowed by the stock configure) then it won't be able to read or produce > svndiff2 deltas, which are used on the wire and may be used in FSFS f8 > on-disk data. If

Re: Subversion1.10.0 up for testing/signing

Summary: +1 to release Platform: Debian/stable (stretch 64-bit) Tested: Compared to 1.10.0-rc2: - repository tags have version information changes only - tarballs and zip file have version information, pot file date and filename-in-comment differences only. I ran the tests

Re: SVN working copy split DB vs. working area

Doug Robinson writes: > The general setup is that they want to have a working copy on a > Distributed File System (DFS, e.g. Lustre) and the DFS either is > very slow (when mounted with sufficient support for SQLite) or just > does not work due to a lack of support

Re: Warnings from the bindings

Branko Čibej writes: > I'll take another look. At the very least this should be using the local > frame manager object, which is exception-safe, unlike explicitly pushing > and popping the frame. ImmutableList::for_each iterates and constructs arbitrary types T. The problem

Re: Warnings from the bindings

Philip Martin <phi...@codematters.co.uk> writes: >Iterator iter(get_iterator()); >while (iter.has_next()) > + { > +m_env.PushLocalFrame(10); > function(T(m_env, NativeT(iter.next(; > +m_env.PopLocalFrame(); > +

Re: Warnings from the bindings

Philip Martin <phi...@codematters.co.uk> writes: > Branko Čibej <br...@apache.org> writes: > >> And I don't see these, either. I checked the code and we explicitly use >> a JNI local frame in the core loop of unparseExternals. Try as I might, >> I can't see wh

Re: Warnings from the bindings

Branko Čibej writes: > And I don't see these, either. I checked the code and we explicitly use > a JNI local frame in the core loop of unparseExternals. Try as I might, > I can't see where all those local references could be coming from. ImmutableList::for_each appears to be

Re: Warnings from the bindings

Philip Martin <phi...@codematters.co.uk> writes: > WARNING in native method: JNI call made without checking exceptions > when required to from CallStaticObjectMethod > > but it's not clear to me which bit of source code is responsible. This might be a false alarm. From

Re: Warnings from the bindings

Stefan Sperling writes: > On Fri, Mar 30, 2018 at 09:29:47AM +0200, Branko Čibej wrote: >> I've never seen either of these warnings and I don't see what could've >> changed on the 1.10.x branch to make them suddenly start appearing. > > The Perl one happens on OpenBSD as well.

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

Cummary: +1 to release Platform: Debian/stable (stretch 64-bit) Tested: (local, svn, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb, fsx) (svn, serf) x (fsfs/block) swig-pl, swig-py, swig-rb, ctypes-python (javahl, tigris-javahl) x (fsfs, bdb, fsx) Results: All tests PASS except

Re: rep-cache sanity checks Re: Script to obliterate the most recent revision(s)

Daniel Shahaf writes: > While we're at it, do we check, before using a rep-cache reference, that the > revision:offset coordinates we obtained do in fact refer to a representation? The SHA1 collision detection code means Subversion now does very exact verification of

Re: Rolling 1.10.0-rc2

Julian Foad writes: > How do you feel about the amount of test coverage we are giving this > block-read code so far -- is it sufficient for a 1.10.0 release? And > should I roll RC2 ASAP or not? The block-read fix in STATUS still needs approval. As well as running the

Re: Rolling 1.10.0-rc2

Julian Foad writes: > AFAIK we still need to arrange adequate test coverage for it. Test coverage is provided by the other nominations in STATUS. Apply r1827105, r1827114 and run "make davautocheck BLOCK_READ=1" and see lots of tests FAIL. Apply the 4725 fix and they

Re: Testsuite options

Philip Martin <phi...@codematters.co.uk> writes: > It is even more pointless than that. Looking at the code in > svn_fs_fs__initialize_caches() I see that revprop caching is now enabled > unconditionally for all FSFS access. > > The config setting SVN_FS_CONFIG_FSFS_CAC

Re: svn commit: r1826720 - /subversion/trunk/subversion/libsvn_fs_fs/cached_data.c

Philip Martin <phi...@codematters.co.uk> writes: > It seems wrong for our checksum code to allow the wrong length, but > preventing dump when the data could otherwise be extracted is also > wrong. Perhaps we should simply allow the checksum code to read any > length wh

Re: svn commit: r1826720 - /subversion/trunk/subversion/libsvn_fs_fs/cached_data.c

phi...@apache.org writes: > Author: philip > Date: Wed Mar 14 14:24:36 2018 > New Revision: 1826720 > > URL: http://svn.apache.org/viewvc?rev=1826720=rev > Log: > Add a checksum length verification to the FSFS checksum code. This > may have prevented the issue 4722 checksum bug by making the

Re: Testsuite options

Philip Martin <phi...@codematters.co.uk> writes: > The testsuite already has support for testing with revprop-cache on. It > can be used with svnserveautocheck but is pointless with davautocheck as > mod_dav_svn now enables it by default. It is even more pointless than

Re: [PATCH] Hackathon project: Dumping viewspec

Julian Foad writes: > I haven't looked further into this, but what I think is the core of > the problem is there's no way to generate a WC directory with its > depth set to 'infinity' but sparse inside, without checking out the > whole tree. It might be difficult to do

Testsuite options

Branko Čibej writes: > As long as we have tuning options, we should test them. It's not that > hard to add buildslave configurations. > > As for eliminating them: it would be nice if the server could auto-tune > these parameters, but that is probably not a worthwhile goal to

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Julian Foad writes: > But does that mean this code isn't being tested by any of our manual > or buildbot testing in the last 6 months? Yes, I think so. For svnserve the code only gets enabled when svnserve has block-read enabled and svnserveautocheck doesn't do that. By

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin <phi...@codematters.co.uk> writes: > I've committed and nominated for 1.10. However I have found another > caching problem: > > https://issues.apache.org/jira/browse/SVN-4727 > > Loading my copy of the original Collab Subversion repository (40515 > revi

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin <phi...@codematters.co.uk> writes: > With a small cache the load completes and verification works, but > verfication fails with a large cache: > > * Error verifying revision 11826. > svnadmin: E160004: Corrupt node-revision '5-385.0.r8127/80' > svnadmin: E160

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Branko Čibej <br...@apache.org> writes: > On 15.03.2018 20:38, Philip Martin wrote: >> Philip Martin <phi...@codematters.co.uk> writes: >> >>> I think the raw >>> window cache may have to be modified to include the svndiff version. >> Experi

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin <phi...@codematters.co.uk> writes: > I think the raw > window cache may have to be modified to include the svndiff version. Experimental patch: Index: subversion/libsvn_fs_fs/cached_data.c === --

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Branko Čibej writes: > The svndiff version is embedded in the first 4 bytes of the window data > and should be parsed from there. When we store the data in the raw window cache the svndiff version isn't part of the stored data. When we subsequently retreive the data from the

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Julian Foad <julianf...@apache.org> writes: > Philip Martin wrote: >> cached_data.c:parse_raw_window() where the svndiff version is hard-coded >> to 1 in the call to svn_txdelta_read_svndiff_window. Changing that to 2 >> allows the regression test to pass, t

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin <phi...@codematters.co.uk> writes: > Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes: > >> Philip Martin <phi...@codematters.co.uk> writes: >> >>> That works as expected, but vary the cache size of the load process and >>&

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes: > Philip Martin <phi...@codematters.co.uk> writes: > >> That works as expected, but vary the cache size of the load process and >> it fails. The load succeeds with -M64 and smaller but fails with -M65 >

Re: svnadmin load error with 1.10 that seems to be fsfs cache related

Philip Martin <phi...@codematters.co.uk> writes: > $ svnadmin dump -q repo | svnadmin load -q -M1000 repo2 > svnadmin: E140001: zlib (uncompress): corrupt data: Decompression of > svndiff data failed This is now issue https://issues.apache.org/jira/browse/SVN-4725 -- Philip

svnadmin load error with 1.10 that seems to be fsfs cache related

Julian Foad writes: > Julian Foad wrote on 2018-02-28: >> I'm happy to announce the release of Apache Subversion 1.10.0-rc1. > > That was 2 weeks ago and we need an RC2. svnadmin create repo svn -mm mkdir file://`pwd`/repo/subversion svn -mm mkdir

Re: SHA-1 collision in repository?

Philip Martin <phi...@codematters.co.uk> writes: > https://issues.apache.org/jira/browse/SVN-4722 I've proposed a fix in STATUS. -- Philip

1.8 suboptimal rep-cache deduplication

Philip Martin <phi...@codematters.co.uk> writes: > My reproduction doesn't trigger the bug in 1.8 but that seems to be > because 1.8 has some other problem and the rep-cache deduplication > doesn't trigger. The third commit restoring the content in the first > commit simply

Re: SHA-1 collision in repository?

Nathan Hartman writes: > Is it possible and does it make sense to always continue reading until > EOF, when the read is either 0 or < 16k? In other words to eliminate > the comparison against the expanded size? I believe setting the expanded size correctly is the only

Re: Potential regression: high server-side memory consumption during import

Julian Foad writes: > Can someone file an issue in the tracker please. I need to refer to it > in discussion with potential rc1 trials. https://issues.apache.org/jira/browse/SVN-4723 -- Philip

Re: SHA-1 collision in repository?

Julian Foad writes: > Please would you file this issue in the issue tracker so I can give > outsiders a reference to it? https://issues.apache.org/jira/browse/SVN-4722 My reproduction doesn't trigger the bug in 1.8 but that seems to be because 1.8 has some other problem

Re: SHA-1 collision in repository?

Philip Martin <phi...@codematters.co.uk> writes: > svn cat http://svn.apache.org/repos/asf/subversion/trunk/INSTALL@1826165 > f1 > (for i in `seq 0 8712`;do echo -n $i;done && echo -n 1) > f1 > svnadmin create repo > svnmucc -mm -U file://`pwd`/repo put f1

Re: SHA-1 collision in repository?

Philip Martin <phi...@codematters.co.uk> writes: > (for i in `seq 0 8712`;do echo -n $i;done && echo -n 1) > f1 Oops, that should be > f2 -- Philip

Re: SHA-1 collision in repository?

Nathan Hartman writes: > That makes me wonder why this has not triggered more frequently for > users? Is there some obscure set of circumstances that triggers this > code path in this particular way? If so, can a test be added to the > test suite to prevent this sort of

Re: SHA-1 collision in repository?

[Moving this to the dev@s.a.o list.] Well done! It looks like you have identified a serious bug here. The function svn_fs_fs__get_contents_from_file() that was recently added to 1.9 for the SHA1 collision detection so the code is new and it is also different from that on trunk. Your proposed

Re: Potential regression: high server-side memory consumption during import

Branko Čibej writes: > In other words ... if we wanted to make authz changes have immediate > effect, we'd need a better (faster, or at least non-blocking) way to > determine that the rules changed than reading the authz file, even if Relatively easy to do for in-repository

Re: Potential regression: high server-side memory consumption during import

Branko Čibej writes: > So if I understand this debate correctly: The authz code is so much > faster now that parsing the authz file and performing the authz lookups > beats calculating its MD5 checksum? More that reading/checksumming is still too slow to be done repeatedly.

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > r1825778 contains a revert of a change not in 1.10, so doesn't merge > cleanly to 1.10. The reverse merge of -c-r1779188,-1778923 from trunk > does merge cleanly to 1.10. However, r1825736 is already nominated, so I just need

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > Stefan Sperling <s...@elego.de> writes: > >> I think our best course of action is to revert the change on trunk >> and in 1.10.x. Could you do that? (I could do it, too. I'm just asking >> you since you've pro

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling writes: > I think our best course of action is to revert the change on trunk > and in 1.10.x. Could you do that? (I could do it, too. I'm just asking > you since you've probably already prepared it in a local copy.) OK, r1825778. Hmm, it doesn't merge cleanly

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling writes: > Which leads me to believe that r1778923 may have been based on wrong > assumptions about performance. The new authz is not fast enough to > significantly reduce per-request overhead. My testing so far was with a very small authz file -- only a handful of

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > Here are the cache stats before/after a run once the timing has > stabilised: > > gets : 11770766, 4388248 hits (37.28%) > sets : 7309448 (99.01% of misses) > failures: 0 > used : 777 MB (94.56%) of 822 MB data cache

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling writes: > Regardless, could you try one more test run with this diff against > trunk to see if it has any impact already? That's slower than current trunk: 6.2s 4.1s 4.5s 4.7s 4.7s 4.6s 4.7s and memory use is back to several GB. -- Philip

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > Note an odd effect in the above numbers. The second run for 1.11 is > always the fastest. The first run in each case is the slowest, the > Subversion cache is cold. The second run is faster, the Subversion > cache is hot.

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling writes: > I may have found a way to store an svn_repos_t object on the connection. > Does it help? (authz_tests pass) No significant improvement. I am timing time svn log http://localhost:/repos/asf/subversion \ --username pm --password mp > /dev/null

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > Again, 1.10 would be nearly twice as fast, but now rereading the authz > removes most of that gain. I think I see the underlying problem: the authz code now incorporates a cache based on the md5 checksum of the rules, so wh

Re: Potential regression: high server-side memory consumption during import

Philip Martin <phi...@codematters.co.uk> writes: > All of those figures are the first run after starting Apache, i.e. when > the OS cache and the Subversion cache is cold. With a hot Subversion I meant to write "the OS cache is hot and the Subversion cache is cold&quo

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling <s...@elego.de> writes: > On Fri, Mar 02, 2018 at 06:20:48PM +0000, Philip Martin wrote: >> >> Yes, that solves the memory use problem. > > Nice, I'll commit it then. This might not be a final fix but at least > it's a step forward. > >> The

Re: Potential regression: high server-side memory consumption during import

Stefan Sperling writes: > Hmmm. Does this help? The authz_tests pass with it. > > Index: subversion/mod_authz_svn/mod_authz_svn.c > === > --- subversion/mod_authz_svn/mod_authz_svn.c (revision 1825730) > +++

Re: Potential regression: high server-side memory consumption during import

Evgeny Kotkov writes: > Perhaps, a simpler reproduction script would be to issue an 'svn log' for > a medium-sized repository. In my environment, doing so for the trunk of > TortoiseSVN's repository with 25,000 revisions causes the httpd process > to consume up to a

Re: Building Subversion on Debian stretch with serf support

Paul Hammant writes: > Or is there an option to hand `apt-get` that really lassos in the serf > binary for the same of making Subversion with client support for http(s) > checkouts. Typically Debian installs libraries that can be used at runtime but not at build-time and to

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

Summary: +1 to release Platform: Debian/stable (stretch 64-bit) Tested: (local, svn, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb, fsx) swig-pl, swig-py, swig-rb, ctypes-python (javahl, tigris-javahl) x (fsfs, bdb, fsx) Results: All tests PASS except ra-test 13 over http v1

Re: [PATCH] Virtual host mode with user name in URL

Thomas Quinot writes: > [[[ > Fix failure to find repo in virtual host mode if user name present > > * subversion/svnserve/serve.c > (find_repos): In vhost mode, skip past user name and password, > if present. > ]]] > > Index: subversion/svnserve/serve.c >

Re: shelves: system("diffstat -p0 %s")

Daniel Shahaf writes: > Neither of these calls correctly quotes the path that's interpolated > into the command line. Consequently, the wcroot_abspath would be > executed as shell commands. Could that be fixed please? Should probably do utf8 to local conversion as

Re: Reviewing 1.10 APIs & compatibility

Julian Foad writes: > It looks like the behaviour changes in 1.10 are intentional and Good. > > I think the test suite should be updated to accept the old error when > the server is old, like this: I suppose we could change the testsuite along these lines, but I don't see

Re: Reviewing 1.10 APIs & compatibility

Julian Foad <julianf...@apache.org> writes: > Philip Martin wrote: >> First I ran the 1.9 testsuite against 1.10 servers >> over http:// and svn://. [...] > > Philip, please can you tell me how you did this? > > [...] >> I also ran the 1.10 testsuite agai

Re: Reviewing 1.10 APIs & compatibility

Julian Foad <julianf...@apache.org> writes: > Philip Martin wrote: >> First I ran the 1.9 testsuite against 1.10 servers >> over http:// and svn://. [...] > > Philip, please can you tell me how you did this? For http:// --- In the 1.9 build directory fi

Re: svn commit: r1822996 - in /subversion/trunk/subversion: libsvn_subr/x509parse.c tests/libsvn_subr/x509-test.c

Branko Čibej writes: > Backport for 1.10? Yes, it's now in STATUS. -- Philip

Re: x509 AlgorithmIdentifier parameters

Philip Martin <phi...@codematters.co.uk> writes: > A client using openssl 1.0 will connect to a server serving the > RSASSA-PSS cert. Clients using openssl 1.1 fail to verify cert. The > underlying openssl 1.1 error appears to be > > $ openssl s_client -connect localhost

Re: x509 AlgorithmIdentifier parameters

Philip Martin <phi...@codematters.co.uk> writes: > Philip Martin <phi...@codematters.co.uk> writes: > >> In Marc's case getting a new server cert that is not RSASSA-PSS might be >> the best solution. > > r1822996 fixes the x509 parser on trunk. It doesn't

Re: x509 AlgorithmIdentifier parameters

Philip Martin <phi...@codematters.co.uk> writes: > In Marc's case getting a new server cert that is not RSASSA-PSS might be > the best solution. r1822996 fixes the x509 parser on trunk. It doesn't mean that the client will be able to verify the RSASSA-PSS certs (you would need an

Re: x509 AlgorithmIdentifier parameters

Philip Martin <phi...@codematters.co.uk> writes: > Looking back at the original mail it looks as if the error is produced > by x509parse.c:x509_get_alg() via svn_x509_parse_cert(), in particular > it is probably this assumption: > > /* >* assume the algorithm

x509 AlgorithmIdentifier parameters

Marc Strapetz writes: > We have cherry-picked your fix onto 1.9.7 tag but unfortunately it > doesn't solve the problem for the user. Looking back at the original mail it looks as if the error is produced by x509parse.c:x509_get_alg() via svn_x509_parse_cert(), in

Re: Reviewing 1.10 APIs & compatibility

Julian Foad writes: > Julian Foad wrote: >> Another possible approach is to look for compatibility breakage by >> running the 1.9 client and test suite against the 1.10 libraries, >> and indeed different client/server version combinations. I did this recently. 1.9

Re: Problems with commit feature negotiation and write-through proxies

Evgeny Kotkov writes: > I would be fine with this approach as well, but perhaps with a few tweaks: Right, I'll incorporate those changes, test it and commit. -- Philip

Re: Problems with commit feature negotiation and write-through proxies

Evgeny Kotkov <evgeny.kot...@visualsvn.com> writes: > Philip Martin <phi...@codematters.co.uk> writes: > >> In the past we supported different versions on the master and slave and >> we introduced the SVNMasterVersion directive to configure it. >> Unfortunately

Re: Removal of spark buildbot

Gavin McDonald writes: > https://ci.apache.org/builders/serf-sparc64-solaris > shows pending > jobs since last August and the previous > build that actually ran was July last year. > > From what I can tell, the

Problems with commit feature negotiation and write-through proxies

I run a write-through proxy for svn.apache.org using mod_dav_svn's SVNMasterURI directive. Commits now fail when using trunk on the client and slave because they negotiate svndiff2 which the s.a.o master does not support. I can reproduce locally using a trunk slave and 1.9 master: $ svn

  1   2   3   4   5   6   7   8   9   10   >