Stefan Sperling wrote:
> > Can two svnserves share one repository?
>
> Yes. You can run as many server instances as you like, also with
> different access methods (e.g. http:// and svn:// at the same time).
I have read that different access methods can be used simultaneously.
I did not know it wa
On Fri, Feb 11, 2011 at 11:55:08PM +0600, Victor Sudakov wrote:
> Can two svnserves share one repository?
Yes. You can run as many server instances as you like, also with
different access methods (e.g. http:// and svn:// at the same time).
> There will be no data corruption, will there?
In gener
Can two svnserves share one repository? There will be no data
corruption, will there?
Daniel Shahaf wrote:
> Workaround: you could run two svnserves with different configs, one
> allowing only anonymous access and only only authenticated access.
>
> I know httpd has the problem you're describing,
Workaround: you could run two svnserves with different configs, one
allowing only anonymous access and only only authenticated access.
I know httpd has the problem you're describing, I don't recall previous
reports of it with svnserve.
Victor Sudakov wrote on Thu, Feb 10, 2011 at 21:14:24 +0600:
What the "anon-access = none" option does is remove the ANONYMOUS
mech from the list of SASL mechs offered by svnserve (I see this in
tcpflow). If this mech is present in the mech list, the svn client
does not bother to authenticate even if a valid Kerberos ticket is
available.
If the svn client h
For what it's worth, I have run into the same problem and the only
solution I have found is to switch to a different access method. As
best as I can tell svnserve is simply not an option when trying to set
up a repository with path based authentication when select areas are
flagged inaccessible to
The problem is probably in the following. When anon-access is other
than "none", svnserve does not request authentication for some
important operations like "svn log", and I have found no way to force
it to request authentication. This effectively breaks path based
authorization.
I have found som
Dear Colleagues,
I am trying to setup the following policy: a private repository with
some public paths. Is such configuration supported at all?
The following configuration:
== conf/svnserve.conf:
anon-access = read
auth-access = write
authz-db = authz
== conf/authz:
[/]
@noc =
