On 09.01.2014 20:19, Branko Čibej wrote:
> On 09.01.2014 17:09, Mojca Miklavec wrote:
>> I'm unable to reproduce the faulty behaviour if I do a checkout from
>> the same network where the server is located, no matter what I try
>> (upgrading SVN client doesn't "help" triggering the error). Philip
>
Ben Reser writes:
> Actually we know we haven't covered all possibilities. Had someone a while
> back that had mod_security setup in such a way that it was rejecting some
> request methods (think it was POST) without Content-Length (thus breaking
> chunked requests). The behavior didn't fail fo
On 1/9/14, 11:19 AM, Branko Čibej wrote:
> To be clear, I'm not saying that any of these things are configured
> incorrectly; only that they may be interacting with Subversion in a way that
> we
> don't handle well. One of the major differences between 1.7 (which works) and
> 1.8 (which fails) is
On 09.01.2014 17:09, Mojca Miklavec wrote:
> I'm unable to reproduce the faulty behaviour if I do a checkout from
> the same network where the server is located, no matter what I try
> (upgrading SVN client doesn't "help" triggering the error). Philip
> also said that he had no problem doing a chec
On Wed, Jan 8, 2014 at 4:53 PM, Philip Martin wrote:
>
> I get a problem with the checkout from your server using a trunk client.
> Very occasionally the checkout works but most of the time the client
> simply hangs while receiving the first file.
>
> It appears that the client is sending the REPOR
Mojca Miklavec writes:
> On Wed, Jan 8, 2014 at 1:11 PM, Branko Čibej wrote:
>> Hi Mojca,
>>
>> On 07.01.2014 20:58, Mojca Miklavec wrote:
>>> (The other problem with "Error retrieving REPORT" is still a mystery
>>> though.) Mojca
>>
>> I'm assuming your server is somewhere on the IJS network. Ca
On Wed, Jan 8, 2014 at 1:11 PM, Branko Čibej wrote:
> Hi Mojca,
>
> On 07.01.2014 20:58, Mojca Miklavec wrote:
>> (The other problem with "Error retrieving REPORT" is still a mystery
>> though.) Mojca
>
> I'm assuming your server is somewhere on the IJS network. Can you please
> ask the admins ther
Hi Mojca,
On 07.01.2014 20:58, Mojca Miklavec wrote:
> (The other problem with "Error retrieving REPORT" is still a mystery
> though.) Mojca
I'm assuming your server is somewhere on the IJS network. Can you please
ask the admins there if your server is behind a load balancer?
-- Brane
--
Bran
On Tue, Jan 7, 2014 at 8:44 PM, Ryan Schmidt wrote:
> On Jan 7, 2014, at 12:01, Mojca Miklavec wrote:
>> On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
>>
>>> Which version of Apache are you using? Which Apache MPM are you using?
>>
>> Server version: Apache/2.4.7 (Unix)
>>
>> I'm not sure h
On Jan 7, 2014, at 12:01, Mojca Miklavec wrote:
> On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
>
>> Which version of Apache are you using? Which Apache MPM are you using?
>
> Server version: Apache/2.4.7 (Unix)
>
> I'm not sure how to check MPM. I get
>
>> httpd -l
> Compiled in mod
On Tue, Jan 7, 2014 at 7:34 PM, Philip Martin wrote:
>
> So you used dump/load to create a new repository and then replaced the
> old repository with the new repository? If you did that while Apache
> was running, without restarting Apache, then that explains the 'Corrupt
> node-revision' error as
Mojca Miklavec writes:
> Ah, OK, I see it now in the old logs. There are no such lines in the
> latest logs.
> The repository is stored on a local disk. I'm not sure what about
> filesystem is it that you are asking, but here are some possibly
> relevant data:
>
>> cat format
> 5
>> cat db/fs-ty
On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
> Mojca Miklavec writes:
>> On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
>>> Mojca Miklavec writes:
>>>
Yes, there is still a problem after restarting Apache. Even though it
works for me at the moment and I tried fetching from m
Mojca Miklavec writes:
> On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
>> Mojca Miklavec writes:
>>
>>> Yes, there is still a problem after restarting Apache. Even though it
>>> works for me at the moment and I tried fetching from multiple
>>> locations and servers, other users are still e
On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
> Mojca Miklavec writes:
>
>> Yes, there is still a problem after restarting Apache. Even though it
>> works for me at the moment and I tried fetching from multiple
>> locations and servers, other users are still experiencing the same
>> problem.
Mojca Miklavec writes:
> Yes, there is still a problem after restarting Apache. Even though it
> works for me at the moment and I tried fetching from multiple
> locations and servers, other users are still experiencing the same
> problem. Logs on the server confirm that. (Unable to deliver conten
On Tue, Jan 7, 2014 at 12:41 PM, Philip Martin wrote:
> Mojca Miklavec writes:
>
>> We have a server running Fedora which has recently been upgraded to
>> version 20 and it's now running
>> svn, version 1.8.5 (r1542147)
>>
>> I have a bunch of repositories served over http protocol with public
Mojca Miklavec writes:
> We have a server running Fedora which has recently been upgraded to
> version 20 and it's now running
> svn, version 1.8.5 (r1542147)
>
> I have a bunch of repositories served over http protocol with public
> read access and limited commit access.
>
> Shortly after th
Hello,
We have a server running Fedora which has recently been upgraded to
version 20 and it's now running
svn, version 1.8.5 (r1542147)
I have a bunch of repositories served over http protocol with public
read access and limited commit access.
Shortly after the upgrade a weird behaviour has
19 matches
Mail list logo
