Johan Corveleyn wrote:
> On Tue, Oct 14, 2014 at 5:00 AM, Perry Hutchison
> wrote:
> > Stefan Sperling wrote:
> >> On Fri, Oct 10, 2014 at 10:27:46AM +0200, Stefan Sperling wrote:
> >> > On Fri, Oct 10, 2014 at 12:53:16AM -0700, Perry Hutchison wrote:
> >> > > ...
> >> > > It appears that I ca
> -Original Message-
> From: users-return-22344-mr_kernel=163@subversion.apache.org
> [mailto:users-return-22344-mr_kernel=163@subversion.apache.org] On
> Behalf Of Branko ?ibej
> Sent: Wednesday, October 15, 2014 1:07 PM
> To: users@subversion.apache.org
> Subject: Re: Wait for hou
James writes:
>$svn merge svn://192.168.0.9/myRepos/myProject/trunk
> Then get above error.
The error E220001 is SVN_ERR_AUTHZ_UNREADABLE so the failure is due to
Subversion's path-based authz rules. The file conf/svnserve.conf in the
repository defines the authz-db file and the aut
On 10/15/2014 01:23 AM, Philip Martin wrote:
Checked the issue using SVN trunk. It does not abort like 1.8.10, but
it does report tree conflicts for d1/f1 and d1. I would say such
conflicts should be resolved automatically, given that the working
copy contains exactly the same changes as in the
This is could be a question for an Apache-related mailing list.
However, it is difficult to tell, because your statement of the problem
doesn't really include enough information. How is it not working? Any
errors in any of the log files? What are you expecting? Are people not
being authorized, or
SVN version 1.8.10 (r1615264), in Fedora 20.
I got above error when I try to merge a trunk to branch before I apply my
changes to the trunk from the branch.
I was able to check out the branch, modify the code and commit back to server
and update the branch to the latest reversion. The same is
On Wed, Oct 15, 2014 at 2:10 PM, wrote:
> There is no proxy between the client and server. As my original email stated,
> I could see using netstat that there were tcp connections left in the
> FIN_WAIT_2 state and the Apache documentation suggests this could be a bug in
> the client. Also as
Hi,
We are using the below mentioned configuration for multiple ldap domain
authentication but one of the domain(ldap2) is not working.
May I know what is wrong with this?
==
LoadModule dav_svn_module
writes:
> Whatever the problem is, when I disable Keepalive I can't browse the
> repositories from a
> browser.
> http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate
> suggests it is a serf bug.
No, it cannot be a serf bug. The browser doesn't use se
On 15.10.2014 14:00, Philip Martin wrote:
> writes:
>
>> When I initially used the default skelta-mode, small checkouts and
>> commits worked perfectly fine. Large checkouts or commits would begin
>> normally but the file transfer rate would quickly drop to 0 and the
>> operation would time out.
There is no proxy between the client and server. As my original email stated, I
could see using netstat that there were tcp connections left in the FIN_WAIT_2
state and the Apache documentation suggests this could be a bug in the client.
Also as the Apache documentation suggested, disabling Keep
writes:
> When I initially used the default skelta-mode, small checkouts and
> commits worked perfectly fine. Large checkouts or commits would begin
> normally but the file transfer rate would quickly drop to 0 and the
> operation would time out. Increasing MaxKeepAliveRequests to 1000
> didn't
When I say we upgraded from 1.7 to 1.8, we configured and deployed a new server
running CollabNetSubversion-server-1.8.9-2-Win32 that replaced our 1.7 server.
All clients uninstalled 1.7, reinstalled 1.8 and rebooted.
I just tried setting SVNAllowBulkUpdates to Prefer and I re-enabled KeepAliv
Alexey Neyman writes:
> Actually, looking at the commit I came up with a reproduction scenario:
Thanks for that! I've created an issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=4524
> Checked the issue using SVN trunk. It does not abort like 1.8.10, but
> it does report tree confli
14 matches
Mail list logo
