New featurer request: Variable support in the config file

svnserve.conf.tmpl So it would be desirable if variables were supported in the config file, such as %{REPO_NAME}%. Thus all repositories can share a single config file. Further more, I'k like to see that Subversion could have the same design in config and Authz files like Apache httpd. Thanks. Best regards, -- Martin Young

Re: Switching from SHA1 to a checksum type without known collisions in 1.15 working copy format

hash function will just solve the problem for a few years... Best regards, Martin

Re: svn copy --pin-externals pins relative paths to non existing revision/path

bda" will not exist in the new tag and keep it untouched at "../B/lambda lambda". Even if the actual new revision can not be known by the client, it knows that it must be at least HEAD+1, so @2 does for sure not exist. I hope I didn't miss anything. Best regards, Martin On 1

svn copy --pin-externals pins relative paths to non existing revision/path

_64-pc-linux-gnu - svn, version 1.14.1 (r1886195) - svn, version 1.13.0 (r1867053)   compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu - svn, version 1.10.6 (r1863367) Best regards Martin repro-template.sh Description: application/shellscript

Re: Feature request: expand the svn:auto-props glob patterns to include GNU extensions

ops section and new style auto-props file. - Martin

Re: A strong WTF on compiling out plaintext password support by default?!

-stores" config they could also delete that library. Martin

Re: Migrate off Freenode IRC?

with two connections. To configure it you have to add a second server alias in the [bot] section, duplicate the plugin section and rename the connection and the section. - Martin

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 eve

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 i

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 e

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 config:auth:ssl-client-c

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

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 acceptabl

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. Tha

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 p

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&view=rev > Log: > On the '1.10.x-issue4758' branch: Fix SVN-4758 "Unable to shelve changes > when using custom diff-cmd". > + /* Ensure we

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

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 no

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: it

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 c

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() h

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 = @GuserA, @GuserB > > [/]

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 --enable-dso, which b

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

Philip Martin writes: > Philip Martin 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 libra

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

Philip Martin 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 libraries do not really have a publ

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? > > [[[ > Fixes libs

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 only be used if the O

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 committed r1829344 so that config

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 on

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 for SQLite - likely locking).

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 occurs when T is Ext

Re: Warnings from the bindings

Philip Martin writes: >Iterator iter(get_iterator()); >while (iter.has_next()) > + { > +m_env.PushLocalFrame(10); > function(T(m_env, NativeT(iter.next(; > +m_env.PopLocalFrame(); > + } >return function; Re

Re: Warnings from the bindings

Philip Martin writes: > 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

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 the problem. The fo

Re: Warnings from the bindings

Philip Martin 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 https://github.com/dropbox/

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. It is not new. I do

Warnings from the bindings

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 /home/pm/sw/subversion/sign/build/subversion/bindings/swig/perl/native/blib/lib/SVN/Core.pm line 58. Core.pm:58 is a call

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 rep-cache references. Subve

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 regression tests with bloc

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 PASS. > * revprop cachi

Re: Testsuite options

Philip Martin 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_CACHE_REVPROPS is public in > svn

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

Philip Martin 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 when rb->len is zero? That doe

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&view=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 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 that. Looking at th

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 automatically, but there i

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 spend > our efforts a

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 invoking svnserve manua

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

Philip Martin 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 > revisions) fails when the ca

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

Philip Martin 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: E160004: Reading one sv

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

Branko Čibej writes: > On 15.03.2018 20:38, Philip Martin wrote: >> Philip Martin writes: >> >>> I think the raw >>> window cache may have to be modified to include the svndiff version. >> Experimental patch: > > Looks approximately correct to me.

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

Philip Martin 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 === --- subversion/libsvn_fs_fs/cached_

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 cache the svndiff v

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

Julian Foad 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, the question is where should the >>

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

Philip Martin writes: > Evgeny Kotkov writes: > >> Philip Martin 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 >>> and larger: &

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

Evgeny Kotkov writes: > Philip Martin 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 >> and larger: > > [...] > > Maybe this behavior could be re

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

Philip Martin 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 file://`pwd`/repo/subversion/trunk ^/subversion/

Re: SHA-1 collision in repository?

Philip Martin 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 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 stores a new delta. Com

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 fix we need. > Alternative

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 and the rep-cache dedupl

Re: SHA-1 collision in repository?

Philip Martin 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 f > svnmucc -mm -U file://`

Re: SHA-1 collision in repository?

Philip Martin 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 thing from slipping in aga

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 fi

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 authz. We could make

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. 1.9 reads the file o

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

Philip Martin 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 to add r1825778 to that :-) -- Philip

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

Philip Martin writes: > 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 co

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 into 1.10... -- P

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 rules and alias

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

Philip Martin 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 / 958 MB total cache memory >

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 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. In 1.9 subsequent runs are compa

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 and I realised

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

Philip Martin 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 when the rules are unchanged the cached val

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

Philip Martin 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" > cache the values are: > &

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

Stefan Sperling writes: > On Fri, Mar 02, 2018 at 06:20:48PM +, 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. > >> There

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) > +++ subversion/mod_authz_svn

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 1 GB of RAM while processing

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 get build-time suppor

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 (this

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 well. -- Philip

Re: x509 AlgorithmIdentifier parameters

Thomas Singer writes: > Hi Philip, > > Thank you for your effort in analyzing this bug and finding > work-arounds or fixes. > > We are using a magic script to build all subversion dependencies, > e.g. openssl-1.0.2 and cyrus-sasl-2.1.26. I've used the master branch > from

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 it as something we have

Re: Reviewing 1.10 APIs & compatibility

Julian Foad 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 against 1.9 servers over http:// an

Re: Reviewing 1.10 APIs & compatibility

Julian Foad 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 first run 1.9 davautocheck.sh

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

  1   2   3   4   5   6   7   8   9   10   >