[Insight-developers] Problems accessing gerrit

[Bill Lorensen]

I often need to try a couple of times. However, earlier today when I
reported the issue, I tried dozens of times.

As I said in my last e-mail, it seems to be working now.

Thanks,

Bill


On Tue, Dec 28, 2010 at 2:03 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Like I said - we are looking into it. HTTP should work, and that is
> what the dashboards are using too. I was offering an alternative in
> the short term if you continued to have trouble. I would certainly
> appreciate you letting us know if the HTTP transport continues to have
> problems. Often you can try a second time and it will work.
>
> Marcus
>
> On Tue, Dec 28, 2010 at 1:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Still probelms:
>>  git fetch http://review.source.kitware.com/p/ITK
>> refs/changes/30/630/1 && git checkout FETCH_HEAD -b
>> FasterIncrementInput
>> error: RPC failed; result=22, HTTP code = 503
>> fatal: The remote end hung up unexpectedly
>>
>> I've been using the anonymous http for months...
>>
>> Ooops, just tried again and it worked.
>>
>> On Tue, Dec 28, 2010 at 1:47 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> On Tue, Dec 28, 2010 at 12:04 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>> Folks,
>>>>
>>>> When I do:
>>>> git fetch http://review.source.kitware.com/p/ITK refs/changes/30/630/1
>>>> && git checkout FETCH_HEAD -b FasterIncrementInput
>>>>
>>>> I get the errors:
>>>> error: RPC failed; result=22, HTTP code = 503
>>>> fatal: The remote end hung up unexpectedly
>>>>
>>>>
>>>> I do this this error occasionally, but a second or third try usually works.
>>>>
>>>> Currently, I am getting this consistently.
>>>>
>>> Matt has taken a look at the server, and upgraded to 2.1.6.1. We will
>>> keep an eye out - please let us know if this continues to happen. Matt
>>> also posted to the Gerrit list to see if others are aware of the
>>> issue. The non-standard SSH port should be open to the outside now
>>> too, and that transport does seem to be more reliable. You may want to
>>> try that, but I would like to ensure the HTTP transport works
>>> reliably.
>>>
>>> Marcus
>>>
>>
>