Re: Subversion 1.10 RC1?

Op 5 dec. 2017 22:13 schreef "Evgeny Kotkov" : Stefan Fuhrmann writes: > There seems to be little that could be done here (suggestions welcome). > The problem is that the asterisk is being expanded by the shell itself. > I made SVN print its

Re: Subversion 1.10 RC1?

On 05.12.2017 22:12, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > >> There seems to be little that could be done here (suggestions welcome). >> The problem is that the asterisk is being expanded by the shell itself. >> I made SVN print its command line parameters and this

Re: Subversion 1.10 RC1?

Stefan Fuhrmann writes: > There seems to be little that could be done here (suggestions welcome). > The problem is that the asterisk is being expanded by the shell itself. > I made SVN print its command line parameters and this is the result: > > $

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

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 large imports. In my environment, when I

Re: Reviewing 1.10 APIs & compatibility

On Dec 5, 2017 10:27, "Julian Foad" wrote: One task in the 1.10 release process is reviewing API changes. One way, that I use myself, is to take a library at a time and compare the 1.9 and 1.10 public headers, looking for procedural errors (e.g. how new and deprecated

Reviewing 1.10 APIs & compatibility

One task in the 1.10 release process is reviewing API changes. One way, that I use myself, is to take a library at a time and compare the 1.9 and 1.10 public headers, looking for procedural errors (e.g. how new and deprecated APIs are marked up, undocumented parameters, etc.) and for possible

A server-side merkle-tree capability for ordinary Subversion* installs.

Implementation here - https://github.com/paul-hammant/SvnMerkleizer. It is written In Java in about 600 lines of code. There's unit and integration tests too (coverage between those two is 92%). In operation it is pretty slow to build caches, but performs really well after that when there's not

Re: [PATCH] release.py: write-changelog function (POC)

On 04.12.2017 23:01, Julian Foad wrote: > Johan Corveleyn wrote: >> [...] >> Hm, yes, I agree with the "don't write the same thing twice". But >> perhaps the "general description" above the list of affected files >> would be a better place: > [...] >> Though, indeed, we're not required to always