On Sat, Jun 22, 2013 at 07:39:23PM -0400, Greg Stein wrote:
> The flag could be something like "busted-proxy = on". When you start
> seeing blog posts like "In order to checkout from EXAMPLE.COM, you
> must set busted-proxy=on in your .subversion configuration", and that
> gets back to EXAMPLE.COM
On Jun 23, 2013 4:54 AM, "Daniel Shahaf" wrote:
>
> On Sat, Jun 22, 2013 at 07:39:23PM -0400, Greg Stein wrote:
> > The flag could be something like "busted-proxy = on". When you start
> > seeing blog posts like "In order to checkout from EXAMPLE.COM, you
> > must set busted-proxy=on in your .subv
Stefan,
this issue is unrelated to ssl tunnelling or authentication, or more
in general unrelated to ra_serf.
The particular scenario here is a user updating a directory with both
local property changes and incoming property changes. Svn then calls
TSVN code to check if the user cancelled the ac
On Thu, Jun 20, 2013 at 4:43 PM, Rainer Jung wrote:
> Hi there,
>
> I built and tested svn 1.8.0 today on Solaris 0 Sparc and got lots of
> test failures due to core dumps.
>
> The first few dumps I inspected all showed a bus error in
>
> #0 0xfe660760 in cache_lookup (path=0x10fce06 "/A/D/H/pi3"
On 23.06.2013 15:07, Lieven Govaerts wrote:
Stefan,
this issue is unrelated to ssl tunnelling or authentication, or more
in general unrelated to ra_serf.
The particular scenario here is a user updating a directory with both
local property changes and incoming property changes. Svn then calls
T
On Sun, Jun 23, 2013 at 4:29 PM, Stefan Küng wrote:
> On 23.06.2013 15:07, Lieven Govaerts wrote:
>> Stefan,
>>
>>
>> this issue is unrelated to ssl tunnelling or authentication, or more
>> in general unrelated to ra_serf.
>>
>> The particular scenario here is a user updating a directory with both
On Sun, Jun 23, 2013 at 3:20 AM, Greg Stein wrote:
> On Sat, Jun 22, 2013 at 3:26 PM, Lieven Govaerts wrote:
>> On Sat, Jun 22, 2013 at 7:32 PM, Lieven Govaerts wrote:
>>> Stefan,
>>>
>>> attached patch to serf 1.2.1 should solve this particular type of
>>> crash you reported.
>>>
>>> The patch
On 6/22/13 1:22 AM, Lieven Govaerts wrote:
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
'slow' procedure, and then persists the results http/1.0 vs http/1.1
and chunked-encoding supported somewhere. Like we
> If you really want to push, then "proxy-hates-chunks" could work well.
Oh man. Not "proxy-blows-chunks"? (SCNR.)
1.7.0@1181106 vs. trunk@1495850
Started at Mon Jun 24 00:25:46 UTC 2013
*DISCLAIMER* - This tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Charts of t
On Sun, Jun 23, 2013 at 7:35 PM, Peter Samuelson wrote:
>
>> If you really want to push, then "proxy-hates-chunks" could work well.
>
> Oh man. Not "proxy-blows-chunks"? (SCNR.)
LOL!
Actually, after an offlist email with Daniel, I would like to "insist"
on just calling it "busted-proxy". We do
On Sun, Jun 23, 2013 at 3:56 PM, Blair Zajac wrote:
> On 6/22/13 1:22 AM, Lieven Govaerts wrote:
>> Even better if we could cache this info somewhere automatically. So
>> that the first time svn connects to a server ever it will use this
>> 'slow' procedure, and then persists the results http/1.0
On 06/23/2013 07:47 PM, Greg Stein wrote:
On Sun, Jun 23, 2013 at 3:56 PM, Blair Zajac wrote:
On 6/22/13 1:22 AM, Lieven Govaerts wrote:
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
'slow' procedure, and
13 matches
Mail list logo
