On Thu, Feb 9, 2012 at 11:32 AM, Mark Phippard wrote:
> On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato
> wrote:
>
>> Bah. I'd be surprised if most of our editors supported postfix text deltas.
>> To my knowledge, there is exactly one driver which uses that approach in
>> our own codebase (
Greg Stein writes:
> What happens when you set MAX_NR_CONNS (that's not the right symbol, but
> close) in linsvn_ra_serf/update.c to 2 ? That should eliminate the
> parallelism. If that succeeds, then maybe we can patch 1.7.x in some way to
> allow svnrdump to set that max, yet keep multiple for
On Feb 9, 2012 1:29 PM, "Philip Martin" wrote:
>
> Johan Corveleyn writes:
>
> > The "dangerous behavior" may have been present in 1.7.0 already, but
> > 1.7.3 will be the first release where this appeared to cause a real
> > issue. I mean, for some reason the bug (or manifestation of the
> > "li
On 02/09/2012 12:35 PM, Greg Stein wrote:
> If it is determined that ra_serf's parallelism is at fault here, then we can
> force it to use a single connection for svnrdump. That should make it follow
> the right order.
>
> (and yeah, it sucks when you try to advance the capabilities and get yanked
Johan Corveleyn writes:
> The "dangerous behavior" may have been present in 1.7.0 already, but
> 1.7.3 will be the first release where this appeared to cause a real
> issue. I mean, for some reason the bug (or manifestation of the
> "lingering bug") first appeared on 1.7.x after r1239697 (backpor
On Thu, Feb 9, 2012 at 6:32 PM, Mark Phippard wrote:
> On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato
> wrote:
>
>> Bah. I'd be surprised if most of our editors supported postfix text deltas.
>> To my knowledge, there is exactly one driver which uses that approach in
>> our own codebase (t
On Feb 9, 2012 12:26 PM, "C. Michael Pilato" wrote:
>
> On 02/09/2012 11:41 AM, Philip Martin wrote:
> > "C. Michael Pilato" writes:
> >
> >> On 02/09/2012 05:22 AM, Philip Martin wrote:
> >>> Hyrum K Wright writes:
> >>>
> Is there any sense of closure on the serf+windows test failure on t
On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato wrote:
> Bah. I'd be surprised if most of our editors supported postfix text deltas.
> To my knowledge, there is exactly one driver which uses that approach in
> our own codebase (the commit driver). So, I can easily forgive svnrdump's
> dump
On 02/09/2012 11:41 AM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> On 02/09/2012 05:22 AM, Philip Martin wrote:
>>> Hyrum K Wright writes:
>>>
Is there any sense of closure on the serf+windows test failure on the
1.7.x branch? My sense is that the failure does *not* expos
"C. Michael Pilato" writes:
> On 02/09/2012 05:22 AM, Philip Martin wrote:
>> Hyrum K Wright writes:
>>
>>> Is there any sense of closure on the serf+windows test failure on the
>>> 1.7.x branch? My sense is that the failure does *not* expose a new
>>> bug on the branch, but rather smokes out
On Thu, Feb 9, 2012 at 10:13 AM, C. Michael Pilato wrote:
> On 02/09/2012 05:22 AM, Philip Martin wrote:
>> Hyrum K Wright writes:
>>
>>> Is there any sense of closure on the serf+windows test failure on the
>>> 1.7.x branch? My sense is that the failure does *not* expose a new
>>> bug on the br
On 02/09/2012 05:22 AM, Philip Martin wrote:
> Hyrum K Wright writes:
>
>> Is there any sense of closure on the serf+windows test failure on the
>> 1.7.x branch? My sense is that the failure does *not* expose a new
>> bug on the branch, but rather smokes out an existing one.
>
> That's my view
Hyrum K Wright writes:
> Is there any sense of closure on the serf+windows test failure on the
> 1.7.x branch? My sense is that the failure does *not* expose a new
> bug on the branch, but rather smokes out an existing one.
That's my view as well. svnrdump has a bug that causes it to rely on
t
13 matches
Mail list logo
