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 command line parameters and this is the result:
>
>
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 is the result:
>>
>>
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:
>
> $ ./subversion/svn/svn ls svn://localhost/
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 `svn import` an unpacked v
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 APIs are marked up, undocum
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
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 ma
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 ha
8 matches
Mail list logo