On 11 December 2015 at 04:12, Branko Čibej wrote:
> On 10.12.2015 18:23, Ivan Zhakov wrote:
>> I think returning
>> hash with non-standard hash function from public API is a bug (and API
>> regression). Other API users may get to the same situation. So proper
>> fix would be revert these optimizat
On 11 December 2015 at 06:18, William A Rowe Jr wrote:
> Which public API, APR's or svn's?
>
Subversion's. Sorry I forgot that dev@a.a.o list is in cc.
--
Ivan Zhakov
Which public API, APR's or svn's?
On Dec 10, 2015 11:24 AM, "Ivan Zhakov" wrote:
> On 10 December 2015 at 20:20, Julian Foad wrote:
> > Ivan Zhakov wrote:
> >> On 10 December 2015 at 19:14, Julian Foad
> wrote:
> >>> APR devs, Subversion devs:
> >>>
> >>> On Subversion's Mac OS buildbots it ap
On 10.12.2015 18:23, Ivan Zhakov wrote:
> I think returning
> hash with non-standard hash function from public API is a bug (and API
> regression). Other API users may get to the same situation. So proper
> fix would be revert these optimizations from public API imo.
I really can't agree with this
On 10.12.2015 18:23, Ivan Zhakov wrote:
On 10 December 2015 at 20:20, Julian Foad wrote:
Ivan Zhakov wrote:
On 10 December 2015 at 19:14, Julian Foad wrote:
APR devs, Subversion devs:
On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
sometimes returns a hash containing d
On 10 December 2015 at 20:20, Julian Foad wrote:
> Ivan Zhakov wrote:
>> On 10 December 2015 at 19:14, Julian Foad wrote:
>>> APR devs, Subversion devs:
>>>
>>> On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
>>> sometimes returns a hash containing duplicate keys, which (as I
Ivan Zhakov wrote:
> On 10 December 2015 at 19:14, Julian Foad wrote:
>> APR devs, Subversion devs:
>>
>> On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
>> sometimes returns a hash containing duplicate keys, which (as I
>> understand it) should be impossible.
>>
>> We had an
Are both hash tables created with the same hash function? (I think stefan2
introduced some variants).
Otherwise I would expect some key values to be changed somewhere after adding
to the first hashtable… But I don’t think this is really a likely scenario.
Bert
Sent from Outlook Mail for Windows
On 10.12.2015 17:35, br...@apache.org wrote:
> Author: brane
> Date: Thu Dec 10 16:35:22 2015
> New Revision: 1719107
>
> URL: http://svn.apache.org/viewvc?rev=1719107&view=rev
> Log:
> Update the gnupg module to the author's most recent version to support
> new features in gpg 2.1.3 [1].
I did th
On 10 December 2015 at 19:14, Julian Foad wrote:
> APR devs, Subversion devs:
>
> On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
> sometimes returns a hash containing duplicate keys, which (as I
> understand it) should be impossible.
>
> We had an issue where some 'svnmover' t
APR devs, Subversion devs:
On Subversion's Mac OS buildbots it appears that apr_hash_overlay()
sometimes returns a hash containing duplicate keys, which (as I
understand it) should be impossible.
We had an issue where some 'svnmover' tests were failing only on Mac
OS buildbots. I added some debug
(Just changing the subject line.)
On 10 December 2015 at 15:23, Philip Martin wrote:
> Julian Foad writes:
>
>> Stepping back a little, I want to pose the rhetorical question: Who is
>> to say which FS layer implementation is the wrong one? BDB is the
>> earlier implementation. If we define corr
Julian Foad writes:
> Stepping back a little, I want to pose the rhetorical question: Who is
> to say which FS layer implementation is the wrong one? BDB is the
> earlier implementation. If we define correctness by precedent, then
> it's the FSFS behaviour that we should consider to be wrong. On
Philip Martin wrote:
> This discussion seems to have died out. Are we going to leave the BDB
> code as is, in which case we should mark the failing test XFAIL, or make
> a change? I still prefer the option that makes the root path mutable on
> commit, primarily because for the vast majority of co
"Bert Huijben" writes:
>> I prefer the solution that makes the root path mutable before commit so
>> that the revision has a distinct root node-revision-id.
>
> I don't know which solution is better. I just posted the other option.
This discussion seems to have died out. Are we going to leave t
On 09.12.2015 18:25, Branko Čibej wrote:
On 09.12.2015 15:13, Stefan Fuhrmann wrote:
On 09.12.2015 13:39, Stefan Fuhrmann wrote:
On 08.12.2015 09:47, Evgeny Kotkov wrote:
The 1.8.15 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.
16 matches
Mail list logo
